Hacker News Reader

Comment by gfodor | Hacker News Reader

I wonder why they didn’t go with the file system permissions on the .auto.conf file, and gracefully handling that as a way to disable the feature. Seems like an obvious solution that doesn’t lead to surprising semantics. The container use case would work fine.

View on HN

One of the authors of the patch here. Two reasons:

1. This config option approach was extremely easy to implement

2. Because making this auto.conf read-only would break many existing tools around Postgres that write to auto.conf

But in this scenario, wouldn't you want to break those tools precisely because they are going around the centralized config from which .conf is supposed to be generated?

But that file gets read at startup. So making changes there is a valid way of making changes.

What you really want is to prevent postgres from writing to that file.

That’s more complicated than just making it write only for everyone. Adding an option to stop postgres from doing what you don’t want it to do makes sense to me.

That is discussed in the comments of the article.

pg applying the change and failing to persist it (in case of a write failure) is the acceptable behaviour probably? Write failures leading to alter failures would count as a surprise.

But after disabling alter system, you can use permissions to avoid local overrides, so this is probably worth adding in the docs.

Reply on news.ycombinator.com