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)
Re: Stefan's bug (was: max_standby_delay considered harmful) |
Список | 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 по дате отправления: