Re: Inadequate thought about buffer locking during hot standby replay
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2012-11-12T14:23:45Z
Lists: pgsql-hackers
On Sun, Nov 11, 2012 at 6:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I already pointed out the inconsistency in heap_xlog_freeze about > whether a cleanup lock is needed. As is, this patch uses a cleanup > lock, but I suspect that a regular lock is sufficient --- comments? Well, according to storage/buffer/README: 1. To scan a page for tuples, one must hold a pin and either shared or exclusive content lock. To examine the commit status (XIDs and status bits) of a tuple in a shared buffer, one must likewise hold a pin and either shared or exclusive lock. That does indeed make it sound like an x-lock is enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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