On 07/30/2013 11:12 AM, Greg Stark wrote:
> But if we're going to insist that conf.d be in PGDATA then I'm saying
> we don't need a second conf.d just to contain that one file. And if we
> let distributions and sysadmins drop files in there then we'll be back
> to square 0 with wanting to separate them.
Ah, misunderstood your point. We certainly don't need *two* conf.d's.
> Greg Smith's argument was about recovery.conf which is a file that
> users are expected to edit. A file which user's are not expected to
> edit and is maintained by the software is no more a configuration file
> than pg_auth or pg_database which are actually being stored in the
> database itself.
I don't think you understood GSmith's argument. For Debian/Ubuntu
sysadmins, configuration files live in /etc/, *period*. Even ones which
were automatically generated. The packagers and scripters of that OS
have taken a significant amount of trouble to make that so, including
writing their own wrapper scripts around utilities for Postgres, Apache,
etc., in order to support putting all configuration files in /etc/.
Now we're proposing to break that *again*, by putting yet another
configuration file in PGDATA, and making it impossible to relocate.
That's fairly hostile to the concerns of possibly our most popular OSes.
Saying "it's not a configuration file because it's automatic" is rather
disingenuous. If you can set work_mem via postgresql.auto.conf, it's a
configuration file, regardless of the means you used to set it.
> Having an automatically maintained file and a manually maintained file
> is going to raise some tricky problems. In Oracle they have exactly
> the same issue. In that case the automatically maintained one is
> actually kept in a binary format. You can dump it out in text format
> but unless you switch which one you're using it doesn't read the text
> format file at all. I assume they did this because working out the
> conflicts between the two was just too complex for users.
I'm not sure we won't end up in the same place as Oracle, eventually.
We'll see.
Re: allowing users to disable ALTER SYSTEM SET, I think we'll have to
implement that before 9.4. comes out, for the simple reason that users
of Puppet and other large-scale configuration management utilities will
demand it. If you're managing 120 PostgreSQL servers using centrally
version-controlled Chef recipes, the last thing in the world you want is
having your DBAs bypass that via ALTER SYSTEM SET.
HOWEVER, I think adding the ability to disable ALTER SYSTEM SET can (and
should) be a second, separate patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com