Re: Explicit config patch 7.2B4

Поиск
Список
Период
Сортировка
От Lamar Owen
Тема Re: Explicit config patch 7.2B4
Дата
Msg-id 200112170243.VAA21871@www.wgcr.org
обсуждение исходный текст
Ответ на Re: Explicit config patch 7.2B4  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Explicit config patch 7.2B4  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sunday 16 December 2001 05:23 pm, Peter Eisentraut wrote:
> I'm still not happy about this, because given a pre-configured or already
> running system it is difficult or impossible to find out which
> configuration file is being used.  This offsets in many ways the improved
> usability you're trying to achieve.

Would -C and its argument not be written to $PGDATA/postmaster.opts if 
started with pg_ctl?  I've not looked at the patch directly, but it would be 
regular behaviour for that to show up, right?  If it's in postmaster.opts, 
then it's trivial to examine and determin where things are coming from.

> I think an 'include' directive for postgresql.conf would solve this
> problem more generally (since it allows many more sharing models) and
> would also give us a good tool when we get to the configuration of
> alternative storage locations.

I like an include directive.  But not for the reasons you like it.

> Probably we could make the option -C to mean "imagine an include directive
> written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
> default empty file this would achieve exactly the same thing as you're
> trying.

No -- he's trying to get the config out of $PGDATA.  The config 
_does_not_belong_with_the_data_.  While it _could_ be put there if the admin 
chooses, it should not be tied to $PGDATA.

I'll have to echo Mark's query, though: Why are you fighting this, Peter?  
This functionality mirrors the standard behaviour for daemons.  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.

I'm willing to compromise to a degree on this issue.  However, Mark already 
has working code.  Sounds like a candidate for a patch -- maybe even a 
feature patch.  And I'll admit to some desire to apply this patch for the 
RPMset -- but I probably won't, as the RPMset shouldn't do anything that 
drastic.  However, it wouldn't surprize me  in the least for a distributor 
such as Red Hat to apply this patch.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: unexpected SIGALRM
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: unexpected SIGALRM