Re:The PostgreSQL community debates ALTER SYSTEM
by gfodor on Sunday April 21, 2024 @02:53PM
(#40108191)
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.
[ Parent
| on HN ]
Re:The PostgreSQL community debates ALTER SYSTEM
by robocat on Sunday April 21, 2024 @03:19PM
(#40108394)
That is discussed in the comments of the article.
Re:The PostgreSQL community debates ALTER SYSTEM
by captn3m0 on Sunday April 21, 2024 @03:14PM
(#40108347)
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.
Re:The PostgreSQL community debates ALTER SYSTEM
by JelteF on Sunday April 21, 2024 @06:00PM
(#40109606)
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
Re:The PostgreSQL community debates ALTER SYSTEM
by int_19h on Sunday April 21, 2024 @10:45PM
(#40111049)
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?
Re:The PostgreSQL community debates ALTER SYSTEM
by MBCook on Sunday April 21, 2024 @10:53PM
(#40111075)
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.