Re: Inadequate thought about buffer locking during hot standby replay - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inadequate thought about buffer locking during hot standby replay
Date
Msg-id 5730.1352753623@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inadequate thought about buffer locking during hot standby replay  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inadequate thought about buffer locking during hot standby replay
List pgsql-hackers
Here's an updated patch that fixes the GIST replay functions as well as
the other minor issues that were mentioned.  Barring objections, I'll
set about back-patching this as far as 9.0.

One thing that could use verification is my fix for
gistRedoPageSplitRecord.  AFAICS, the first page listed in the WAL
record is always the "original" page, and the ones following it are
pages that were split off from it, and can (as yet) only be reached by
following right-links from the "original" page.  As such, it should be
okay to release locks on the non-first pages as soon as we've written
them.  We have to hold lock on the original page though to avoid letting
readers follow dangling right-links.  Also, the update of
NSN/FOLLOW_RIGHT on the child page (if any) has to be done atomically
with all this, so that has to be done before releasing the original-page
lock as well.  Does that sound right?

            regards, tom lane


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inadequate thought about buffer locking during hot standby replay
Next
From: Bruce Momjian
Date:
Subject: Re: Further pg_upgrade analysis for many tables