Re: Race condition between hot standby and restoring a FPW - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Race condition between hot standby and restoring a FPW
Date
Msg-id 54637CE6.7080207@vmware.com
Whole thread Raw
In response to Re: Race condition between hot standby and restoring a FPW  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Race condition between hot standby and restoring a FPW  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/12/2014 05:20 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>> On 11/12/2014 04:56 PM, Tom Lane wrote:
>>> Not great either.  What about an RBM_NOERROR mode that is like RBM_ZERO
>>> in terms of handling error conditions, but does not forcibly zero the page
>>> if it's already valid?
>
>> Anyway, you don't want to read the page from disk, just to check if it's
>> already valid.
>
> Oh, good point.
>
>> (Note that when the page is already in the buffer-cache, RBM_ZERO
>> already doesn't zero the page. So this race condition only happens when
>> the page isn't in the buffer cache yet).
>
> Right.
>
> On reconsideration I think the "RBM_ZERO returns page already locked"
> alternative may be the less ugly.   That has the advantage that any code
> that doesn't get updated will fail clearly and reliably.

Yeah, I'm leaning to that approach as well. It's made more ugly by the 
fact that you sometimes need a cleanup lock on the buffer, so the caller 
will somehow need to specify whether to get a cleanup lock or a normal 
exclusive lock. Maybe add yet another mode, RBM_ZERO_WITH_CLEANUP_LOCK. 
Could also rename RBM_ZERO to e.g. RBM_ZERO_AND_LOCK, to make any code 
that's not updated to break even more obviously, at compile-time.

- Heikki



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Race condition between hot standby and restoring a FPW
Next
From: Tom Lane
Date:
Subject: Re: Race condition between hot standby and restoring a FPW