Skip site navigation (1) Skip section navigation (2)

Re: Parsing config files in a directory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing config files in a directory
Date: 2009-10-26 20:33:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm not sure whether you're saying that I'm bringing this issue up in
> the wrong thread, or whether you disagree with the basic suggestion.

The former --- whether we want to trim down the commentary in
postgresql.conf seems to me to have nothing to do with what's
being discussed in this thread.  As Greg Smith already stated
in a couple of ways, the issue here is about being able to support
**simple** tools that make modifications to system-wide parameter
settings.  Removing default commentary from postgresql.conf does
not help that at all.  Removing the ability to use comments there
at all might help, but if you haven't figured out yet that no such
proposal will fly, I'm not sure how much clearer I can say it.

The desire to not have a ridiculously high bar for config adjustment
tools also seems to me to be plenty of reason to reject the various
odd ideas we have seen like making tools go around and edit files
other than the one they are chartered to put settings in.

> on this thread, you suggested dumping the initdb functions into a
> mostly-empty persistent.conf file that would be read after
> postgresql.conf.  If we did that, then we would presumably advise
> people not to set settings in postgresql.conf because of the
> possibility that they would be overriden in persistent.conf, which
> begs the question of why we need two files at all.

You are confusing who is in charge here.  It's not the tool, it's
the DBA, and anybody who thinks differently is going to keep losing
arguments.  I would actually suggest that it'd be better to put
the include of persistent.conf first, with a comment (!) pointing
out that any subsequent manual settings will override that.  Some
people will choose to use persistent.conf, some won't care to; and
the main problem I'm seeing in this debate is the apparent desire
to force the latter group to do what somebody else thinks is good
for them.  If you design a setup that can be used in multiple styles,
including the old one, you'll have a lot better chance of getting it

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2009-10-26 20:40:17
Subject: Re: Parsing config files in a directory
Previous:From: Josh BerkusDate: 2009-10-26 20:30:00
Subject: Re: Proposal: String key space for advisory locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group