Re: Inadequate thought about buffer locking during hot standby replay

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inadequate thought about buffer locking during hot standby replay
Date: 2012-11-12 20:53:43
Message-ID: 5730.1352753623@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
restore-backup-blocks-individually-3.patch.gz application/octet-stream 19.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-11-12 20:59:27 Re: Further pg_upgrade analysis for many tables
Previous Message Tom Lane 2012-11-12 19:59:21 Re: Inadequate thought about buffer locking during hot standby replay