Re: Overhauling GUCS - Mailing list pgsql-hackers

"Andreas Pflug" <pgadmin@pse-consulting.de> writes:

> Why do so many people here insist on editing postgresql.conf as primary means
> of changing config params?
> Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as good as sed'ing
> postgresql.conf or doing it manually?

no, it's awful.

> Looking around for different approaches, network appliances come to my mind,
> e.g. Cisco routers and PIX. You have 3 ways to configure a pix:
> - use a command line (using ssh or telnet, eqivalent to psql); WRITE MEMORY to
> make the changes survive a reboot.
> - use a web interface (or similar tool)
> - use tftp to up/download the complete config in and out, editing the file.
> User comments will be lost, with the exception of those that have been applied
> with special comment commands (equivalent to "comment on").

And in every major installation I've seen people use the last option. They
treat the original text file which is kept elsewhere -- normally checked into
some revision control system, tracked and managed like source code -- as the
canonical and authoritative version.

The fact that you have to go through an especially complicated and awkward
process to load it onto the switches is just a technical detail to be worked
around. And the fact that somebody could have altered the configuration
directly on the switch and forgotten to write it to the configuration file is
a danger to be worked around with policy, not a benefit.

Essentially what good cisco network admins are doing here is working around
the awkward interface using policy and replacing it with a static text
configuration file kept elsewhere.

Experience with other attempts at automatic tools to edit configuration files
like webmin etc are that editing text files which are also under user control
is just a terrible idea. You can make it almost work but it's always fragile
and can't keep up with the flexibility of free-form text and the creativity of
users.

What I would suggest is going back to the plan when we added include files.
Have an automatically generated config file which is freshly re-generated each
time and doesn't try to preserve any user-formatting. Users then include that
file at the top of postgresql.conf and override any of the settings by setting
them in postgresql.conf after the include.

The important thing here is to separate files which are "under postgres
control" and those "under user control". That doesn't necessarily mean we have
to ban users from touching the automatically generated config file or switch
formats, but it relieves us of any responsibility for maintaining free-form
text.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!