* Alvaro Herrera (alvherre@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
