Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I realize that the current file format is an old and familiar
> friend; it is for me, too. But I think it's standing in the way of
> progress. Being able to type a SQL command to update postgresql.conf
> would be more substantially convenient than logging in as root,
> using su to become postgres, changing to the correct directory,
> starting up vi, finding the right setting, editing it, quitting out,
> and requesting a reload. And I deal with 1 PostgreSQL instance at a
> time, not tens or hundreds or thousands.
Speaking as someone who has to help keep 200 geographically dispersed
PostgreSQL clusters running, I can say that "convenient" ways to
change configuration settings on individual servers has little appeal,
particularly if it makes it harder to enforce configuration policies
or to audit current settings. Generally, before applying any update
or configuration change to production servers we must first apply it
to a development environment and prove that it improves things without
breaking anything, then it can be rolled to a test environment where
those results must be confirmed, and then to a staging environment to
confirm both our install procedures and the behavior of the change
with a large number of testers going through standard scripts for
exercising the application software.
Copying scripts into place and reloading or restarting PostgreSQL is
not an imposition; anything which reduces my confidence in knowing
what configuration is in use is an imposition. Piping a list of
server names through xargs to a deploy script just isn't a big deal,
once we have an acceptable configuration.
We do find the include capabilities useful. For example, for our 72
production servers for county Circuit Court systems, we copy an
identical postgresql.conf file to each county, with the last line
being an include to an overrides conf file in /etc/. For most
counties that file is empty. For counties where we've installed extra
RAM or where data is not fully cached, we override settings like
effective_cache_size or the page costs. I can't see where any of the
options under discussion would do much to help an environment like
ours -- they seem more likely to help shops with fewer servers or more
relaxed deployment procedures.
-Kevin