Re: Inadequate thought about buffer locking during hot standby replay
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2012-11-13T08:49:47Z
Lists: pgsql-hackers
On 12.11.2012 22:53, Tom Lane wrote: > 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. Ok. It won't help all that much on 9.0, though. > 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? Yep. - Heikki
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rewrite the GiST insertion logic so that we don't need the post-recovery
- 9de3aa65f01f 9.1.0 cited