Re: Stefan's bug (was: max_standby_delay considered harmful) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Stefan's bug (was: max_standby_delay considered harmful)
Date
Msg-id AANLkTimnEC47pstVd47KYcPxoc294mutBWYymZYWXqN-@mail.gmail.com
Whole thread Raw
In response to Re: Stefan's bug (was: max_standby_delay considered harmful)  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Stefan's bug (was: max_standby_delay considered harmful)
List pgsql-hackers
On Mon, May 24, 2010 at 10:35 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, May 24, 2010 at 10:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
>
> Okay, how about the attached patch? It uses the postmaster-local flag
> "ReachedEndOfRecovery" (better name?) instead of XLogCtl one.

I've committed part of this patch, with the naming change that Tom
suggested.  The parts I haven't committed are:

1. I don't see why we need to reset ReachedEndOfRecovery starting over
from PM_NO_CHILDREN.  It seems to me that once we reach PM_RUN, we
CAN'T go back to needing the backup label file, even if we have a
subsequent backend crash.  If I'm wrong, please let me know why and
I'll go put this back (with an appropriate comment).

2. The changes to avoid launching WALReceiver except during certain
PM_* states.  It seems fairly sensible, but what is the case where
adding this logic prevents a problem?

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: mapping object names to role IDs
Next
From: Alastair Turner
Date:
Subject: Re: Synchronization levels in SR