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

On Tue, May 18, 2010 at 3:45 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, May 18, 2010 at 3:24 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Tue, 2010-05-18 at 15:09 +0900, Fujii Masao wrote:
>>> On Tue, May 18, 2010 at 2:26 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> > On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
>>> >> On Mon, May 17, 2010 at 9:01 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> >> >> (1)
>>> >> >> Smart or fast shutdown requested in PM_STARTUP state always removes
>>> >> >> the backup_label file if it exists. But it might be still required
>>> >> >> for subsequent recovery. I changed your patch so that additionally
>>> >> >> the postmaster skips deleting the backup_label in that case.
>>> >> >
>>> >> > Don't like the name NeedBackupLabel seems too specific. That really
>>> >> > corresponds to "we were in recovery". We should have a couple of
>>> >> > super-states that correspond to am in recovery/am not in recovery so we
>>> >> > can drive it from that.
>>> >>
>>> >> ISTM that we can use XLogCtl->SharedRecoveryInProgress for that.
>>> >> Is this OK?
>>> >
>>> > That can change state at any time. Would that work?
>>>
>>> Yes. XLogCtl->SharedRecoveryInProgress is set to TRUE only when
>>> XLogCtl structure is initialized (i.e., XLOGShmemInit), and it's
>>> set to FALSE only at the end of recovery.
>>
>> You should be using RecoveryInProgress()
>
> Isn't access to a bool variable atomic?

If it's not atomic, I'll add the following comment into CancelBackup():

Don't bother with lock to access XLogCtl->SharedRecoveryInProgress,
because there should be no other processes running when this code
is reached.

Thought?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center