Re: Race condition between hot standby and restoring a FPW

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Race condition between hot standby and restoring a FPW
Date: 2014-11-12 14:56:45
Message-ID: 23185.1415804205@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-12 15:08:58 Re: Race condition between hot standby and restoring a FPW
Previous Message Alvaro Herrera 2014-11-12 14:56:01 Re: what does this mean: "running xacts with xcnt == 0"