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 23185.1415804205@sss.pgh.pa.us
Whole thread Raw
In response to 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  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> There's a race condition between a backend running queries in hot 
> standby mode, and restoring a full-page image from a WAL record. It's 
> present in all supported versions.

> I can think of two ways to fix this:

> 1. Have ReadBufferExtended lock the page in RBM_ZERO mode, before 
> returning it. That makes the API inconsistent, as the function would 
> sometimes lock the page, and sometimes not.

Ugh.

> 2. When ReadBufferExtended doesn't find the page in cache, it returns 
> the buffer in !BM_VALID state (i.e. still in I/O in-progress state). 
> Require the caller to call a second function, after locking the page, to 
> finish the I/O.

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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: what does this mean: "running xacts with xcnt == 0"
Next
From: Robert Haas
Date:
Subject: Re: Race condition between hot standby and restoring a FPW