Re: Stefan's bug (was: max_standby_delay considered harmful)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Stefan's bug (was: max_standby_delay considered harmful)
Дата
Msg-id AANLkTikgXQ2ofUTp3FdsAawOuqtUxkUQ5TGF6sWJky90@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Stefan's bug (was: max_standby_delay considered harmful)  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Stefan's bug (was: max_standby_delay considered harmful)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Stefan's bug (was: max_standby_delay considered harmful)  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Mon, May 24, 2010 at 1:27 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, May 19, 2010 at 2:47 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> Oh, right. How about allowing the postmaster only in PM_STARTUP,
>>>> PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state to invoke
>>>> walreceiver? We can keep walreceiver alive until all read only
>>>> backends have gone, and prevent unexpected startup of walreceiver.
>>>
>>> Yes, that seems like something we should be checking, if we aren't already.
>>
>> I'll do that.
>
> Here is the updated version. I added the above-mentioned check
> into the patch.

This looks pretty reasonable to me, but I guess I feel like it would
be better to drive the CancelBackup() decision off of whether we've
ever reached PM_RUN rather than consulting XLogCtl.  It just feels
cleaner to me to drive all of the postmaster decisions off of the same
signalling mechanism rather than having a separate one (that only
works because it's used very late in shutdown when we theoretically
don't need a lock) just for this one case.

I could be all wet, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Synchronization levels in SR
Следующее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Exposing the Xact commit order to the user