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

From Tom Lane
Subject Re: Race condition between hot standby and restoring a FPW
Date
Msg-id 4351.1415807254@sss.pgh.pa.us
Whole thread Raw
In response to Re: Race condition between hot standby and restoring a FPW  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Race condition between hot standby and restoring a FPW
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 11/12/2014 05:20 PM, Tom Lane wrote:
>> 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.

Yeah, I was considering suggesting changing the name of the mode too.
+1 for solving the lock-type problem with 2 modes.

(You could also consider leaving RBM_ZERO in place with its current
semantics, but I think what you've shown here is that there is no
safe way to use it, so probably that's not what we should do.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Race condition between hot standby and restoring a FPW
Next
From: Andres Freund
Date:
Subject: Re: what does this mean: "running xacts with xcnt == 0"