Re: archive modules

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: archive modules
Дата
Msg-id 2884265.1663188443@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: archive modules  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: archive modules  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 14.09.22 22:03, Nathan Bossart wrote:
>> I originally did it this way, but changed it based on this feedback [0].  I
>> have no problem with the general idea, but the recovery_target_* logic does
>> have the following note:
>>
>> * XXX this code is broken by design.  Throwing an error from a GUC assign
>> * hook breaks fundamental assumptions of guc.c.  So long as all the variables
>> * for which this can happen are PGC_POSTMASTER, the consequences are limited,
>> * since we'd just abort postmaster startup anyway.  Nonetheless it's likely
>> * that we have odd behaviors such as unexpected GUC ordering dependencies.

> Ah yes, that won't work.  But maybe we can just check it at run time,
> like in LoadArchiveLibrary().

Yeah, the objection there is only to trying to enforce such
interrelationships in GUC hooks.  In this case it seems to me that
we could easily check and complain at the point where we're about
to use the GUC values.

            regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: archive modules
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: archive modules