Re: Explicit config patch 7.2B4

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, mlw <markw(at)mohawksoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit config patch 7.2B4
Date: 2001-12-17 17:30:14
Message-ID: 200112171730.MAA23590@www.wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sunday 16 December 2001 11:13 pm, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > This functionality mirrors the standard behaviour for daemons.

> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon. That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

Really? Most daemons allow a default config location, and then either allow
or require a config file path on the command line. AOLserver _requires_ the
path on the command line; named allows it, sendmail allows it, etc.

I routinely run multiple nameds on machines behind NAT. Just a simple config
file path away. I routinely run multiple instances of other programs as well.

Note that neither I, Mark, Doug, or anyone else is asking for a change in the
default behavior. I personally just want it to be _allowed_ behavior.
Nothing more; nothing less.

> I rather liked Peter's idea of treating the feature as an implicit
> inclusion. Maybe there's an even-better approach out there, but so far
> that's the best idea I've heard.

I rather dislike the idea that $PGDATA is where the config file lives. I
quite particularly dislike the 'implicit include' idea.

> > Name a standard daemon package other than postgresql that
> > automatically assumes the config is with dynamic data, and overwrites
> > an existing config when the dynamic data area is reinitialized.

> initdb will not overwrite an existing config. Try it.

Ok, I'll concede that. But having postgresql.conf in $PGDATA makes it more
difficult for an admin to wipe $PGDATA and start over. For that matter,
pg_hba.conf is there, too, and I disagree that users should be forced to put
it in $PGDATA.

> > However, it wouldn't surprize me in the least for a distributor
> > such as Red Hat to apply this patch.

> Oh, I doubt it...

> regards, tom lane
> Red Hat Database project

Having seen Trond's reply, I have to laugh....as I _know_ he disagrees with
you (and knew such before he replied -- this has been a thorn in his side for
awhile. Might prove to be an interesting 'discussion' inside RH over it.
But, again, an 'optional' command line switch should be a no-brainer. It
just seems to me to be rather unproductive to not allow people more
flexibility in a regular way. Symlinks are not the answer, either.

But RH is not the only distributor of PostgreSQL. And, for the record, the
Debian packages already do something very similar. Wouldn't it be better for
the core package to support this, rather than each distributor doing it
differently from each other?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2001-12-17 17:56:53 Re: Explicit config patch 7.2B4
Previous Message Oliver Elphick 2001-12-17 17:08:59 Re: Explicit config patch 7.2B4