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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
