Re: Race condition between hot standby and restoring a FPW

From: Robert Haas <robertmhaas(at)gmail(dot)com>
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 15:08:58
Message-ID: CA+TgmoZurW5+zY4y6eM3q3sW2k7oETwZxq_sLZgMRGjAH9MOXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 12, 2014 at 7:39 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> 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.

This seems like a reasonable approach.

If you tilt your head the right way, zeroing a page and restoring a
backup block are the same thing: either way, you want to "read" the
block into shared buffers without actually reading it, so that you can
overwrite the prior contents with something else. So, you could fix
this by adding a new mode, RBM_OVERWRITE, and passing the new page
contents as an additional argument to ReadBufferExtended, which would
then memcpy() that data into place where RBM_ZERO calls MemSet() to
zero it.

I'm not sure whether we want to complicate the API that way, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-12 15:13:18 Re: [REVIEW] Re: Compression of full-page-writes
Previous Message Tom Lane 2014-11-12 14:56:45 Re: Race condition between hot standby and restoring a FPW