* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > With this design, if you put enable_alter_system=off in auto.conf, there > is no way for the user to enable alter system again short of editing a > file in the data directory. I think this is one of the things that was > "forbidden" by policy; only files in the config directory needs to be > edited.
If you edit it by hand to begin with (setting that parameter to 'off') then it's reasonable that you may have to edit it by hand again to fix it. If we don't want people to "lock themselves out" by using ALTER SYSTEM to turn it off, then we just disallow that. > What I was proposing upthread is that enable_alter_system=off/on would > be present in postgresql.conf, and there is no include line for > auto.conf. I really think that's a terrible approach, to be honest. I want to see an 'include' line in postgresql.conf for auto.conf, so the hapless sysadmin who is trying to figure out what the crazy DBA did has some clue what to look for. "enable_alter_system" doesn't tell him diddly about an 'auto.conf' file which is included in the system config. > That way, if the user wishes to enable/disable the feature, > they need to edit postgresql.conf to do so. ALTER SYSTEM doesn't offer > a way to disable itself. We can simply disallow ALTER SYSTEM from modifying enable_alter_system; that strikes me as a reasonable thing to do anyway. What I find a bit more worrying is what happens if they decide to put enable_alter_system=off into the postgresql.conf but keep the 'include' line for auto.conf.. Which goes right back to the question that I had before around if we want to complain when the same GUC is seen multiple times during parsing. It seems like there's no hope for it, given the way this has been designed, because you *must* set certain parameters and so you can't simply have them commented out, but those are likely to be parameters which DBAs will want to change through ALTER SYSTEM. Thanks, Stephen
Description: Digital signature