Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
От | Tom Lane |
---|---|
Тема | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |
Дата | |
Msg-id | 28132.1389888775@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Why conf.d should be default, and auto.conf and
recovery.conf should be in it
Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: >> 1. it is to be read automatically by the server without need for an >> "include_dir conf.d" option in the main postgresql.conf. > I am not thrilled with the idea that we're claiming ownership of the > directory which postgresql.conf happens to reside in and you had better > not have any 'conf.d' directory in there unless it's the one for PG. If we were to do this, I'd argue that the location of this hard-wired config directory ought to be selected by a configure option. And in fact, I'd argue that the default behavior with no such option be that there's no such hard-wired directory. That puts it entirely on the packager to decide what makes sense as a location. In the end it's going to be the packager's decision anyway --- it's just a matter of how painful we make it for him to configure it to his distro's conventions. On the whole though, I find the argument that we can't configure this in postgresql.conf to be exceedingly weak. In particular, the idea that you can puppet-ify a configuration without any knowledge of the distro you're targeting is ridiculous on its face, as is the idea that we/postgres can dictate configuration file location conventions to packagers who have distro rules to follow. There isn't going to be a "one location to rule them all", and that means the argument that a location determined by postgresql.conf is too unstable does not really hold water. Another point here is that hard-wiring a config directory location into the executables completely breaks many scenarios for running multiple clusters with the same executables. Yeah, maybe you'd like to share most of the same config across all your clusters. But then again, maybe you wouldn't. The proposed behavior would make it practically impossible for a test cluster to not pick up random subsets of the system primary cluster's configuration. regards, tom lane
В списке pgsql-hackers по дате отправления: