Bruce Momjian wrote:
> Lamar Owen wrote:
>
>>On Monday 27 February 2006 21:09, Bruce Momjian wrote:
>>
>>>One question I have is how this feature would be an improvement over
>>>just pointing pg_ctl at a postgresql.conf configuration file. That
>>>config file has the ability to specify most if not all server
>>>parameters.
>>
>>The big problem is that postgresql.conf is dynamically generated during
>>initdb, and its location depends upon initdb's parameters directly. This
>>makes it difficult to distribute, at least for packagers, a template of
>>postgresql.conf or a 'default' postgresql.conf that plays nice with multiple
>>versions and clusters, yet has centralized database tracking.
>
>
> But looking at postgresql.conf I see:
>
> #data_directory = 'ConfigDir' # use data in another directory
> ...
> #port = 5432
>
> so it seems everything in this configuration file is going to be
> duplicated in postgresql.conf.
>
> We are adding an "include" capability for postgresql.conf. Does that help?
>
> Also, keep in mind this TODO item:
>
> * Allow pg_ctl to work properly with configuration files located outside
> the PGDATA directory
>
> pg_ctl can not read the pid file because it isn't located in the
> config directory but in the PGDATA directory. The solution is to
> allow pg_ctl to read and understand postgresql.conf to find the
> data_directory value.
>
> I am thinking it should be fixed as part of this.
>
> What if we add an option to initdb to allow the user to specify the name
> and location of the postgresql.conf file?
>
That is certainly a way to approach it, I see the tough bit being the
parsing of postgresql.conf to figure out which parts of the global
included file to ignore (i.e the stuff for the *other* clusters).
Would this work for the situation where you have older clusters on the
box (versions that don't understand 'include')?
Additionally this would need to tackle start|stop etc for all clusters...
Cheers
Mark