Re: PostgreSQL configuration

On Mon, 12 Apr 2004, Bruce Momjian wrote:

> pgsql(at)mohawksoft(dot)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.

Well, AFAICS the patch doesn't require that actually, it merely allows the
separation. You can place the data directory in the configuration file
and only use -C, you can place the configuration in the standard place
under data and only use -D or you can specify both on the command line.

I think the real potential harm would be from any current or future
options where it'd be possible to have the system behave improperly when
started up with the wrong value relative to a particular data directory.
This would be especially bad if it was difficult or impossible to realize
that it had happened and might then actually destroy data. I'm reasonably
sure that such an option shouldn't be in an expected to be edited by admin
configuration file, though.