On Tue, Oct 27, 2009 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
>> ... One file per GUC is certainly never going to fly though, it's
>> been hard enough getting people to accept going from one file to more than
> One thing that concerns me a bit about the lack of consensus on that
> is what will happen if different config-adjustment tools adopt different
> philosophies. If Dimitri writes a tool that drops settings into per-GUC
> files, and you write one that puts them all in persistent.conf, and
> somebody tries to use both those tools, no good will come of it.
> If we forgot about the config-dir idea and just had one file that was
> meant to be hacked by automated tools, the problem would go away.
> However I suspect that that proposal won't fly, so we ought to think
> about providing some guidance to tools writers about what to do.
> Is there any consensus on how multiple config files actually get used
> over in the Apache/etc world?
IME, the use case for multiple Apache configuration files is that
there are bits of configuration that support particular modules which
packagers want installed only in conjunction with the corresponding
modules - it has nothing to do with being able to automate config-file
updates, or at least I am not aware that it does.
I think that might be somewhat less of an issue for us, but I'm not
sure. I think we have fewer settings that are absolutely required to
get the system up than Apache. An unscientific survey of one server I
use shows 16 lines of uncommented configuration in postgresql.conf,
vs. 224 in httpd.conf and 95 more in httpd.conf.d/*.conf
In response to
pgsql-hackers by date
|Next:||From: Joshua D. Drake||Date: 2009-10-27 18:10:27|
|Subject: Re: Parsing config files in a directory|
|Previous:||From: Robert Haas||Date: 2009-10-27 17:51:47|
|Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order|