Robert Haas <robertmh...@gmail.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers