Re: PostgreSQL configuration - Mailing list pgsql-hackers
From | pgsql@mohawksoft.com |
---|---|
Subject | Re: PostgreSQL configuration |
Date | |
Msg-id | 17312.24.91.171.78.1081783186.squirrel@mail.mohawksoft.com Whole thread Raw |
In response to | Re: PostgreSQL configuration (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers |
> pgsql@mohawksoft.com wrote: >> > The only other idea I can think of is to create a new pg_path.conf >> file. >> > It would have the same format as postgresql.conf, but contain >> > information about /data location, config file location, and perhaps >> > pg_xlog location. >> > >> > The file would be created by special flags to initdb, and once >> created, >> > would have to be used instead of pgdata for postmaster startup. >> >> That seems like a lot more risky, doesn't it? What is technically bad >> about my patch? Why is it "bad?" Everyone is offering something >> different >> than what I suggest. What is technically wrong with the patch? What can >> I >> alter to correct any concerns? >> >> I'm not a very good at politics, I sometimes tend to alianate people in >> discussions, but I am simply unable to understand why the features I >> suggest are not being considered "as is." I have been using them for a >> while now, I find them very useful, and I have people downloading the >> patch from my site on a regular basis. Yet I an unable to say "Here can >> we >> add this." The response is "We don't like this for x, y, and z," but >> reasons x, y, and z already exist in one form or another in the current >> implementation. >> >> (1) What tangable harm comes to postgresql.conf from these features? >> (2) What problem (security, stabilitry, safety, etc.) is created by >> these >> features that doesn't already exist in some form already. >> (3) Isn't having this as an option "better" than making it normal for >> people to mess around in the PGDATA directory? >> (4) Isn't open source and UNIX phylosophy about providing capability not >> enforcing policy? > > I think the major problem with your -C & -D idea is that you require the > administrator to link the config file and data directory everytime you > start the db, and that might be error-prone. > The patch does no such thing. This is a misunderstanding of the description. (I don't even know where it is in this chain of emails) The -C parameter sets the defaults which can be overridden by the command line, which seems "logical," correct? postmaster -C /etc/db/postgresql.conf Can be sufficient to start PostgreSQL, however, since command line arguments take precedent (as one would expect) postmaster -C /etc/db/postgresql.conf -D /RAID1/test_cluster Also works. PostgreSQL continues to use the defaults it currently does, but the patch adds five extra configuration entries: include = '/etc/postgres/debug.conf' data_dir = '/vol01/postgres' hba_conf = '/etc/postgres/pg_hba_conf' ident_conf = '/etc/postgres/pg_ident.conf' runtime_pidfile = '/var/run/postgresql.conf' The order of default is this: PostgreSQL default, configuration default, and finally command line. Lastly, do not confuse "runtime_pidfile" with the PID stored in $PGDATA. It is separate, it is used ONLY for external administration utilities that assume something like /var/run/foobar.pid
pgsql-hackers by date: