Re: PostgreSQL configuration

> 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