Re: Inadequate thought about buffer locking during hot standby replay

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers@postgresql.org, daniel@heroku.com
Date: 2012-11-10T17:41:27Z
Lists: pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 9 November 2012 23:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm inclined to think that we need to fix this by getting rid of
>> RestoreBkpBlocks per se, and instead having the per-WAL-record restore
>> routines dictate when each full-page image is restored (and whether or
>> not to release the buffer lock immediately).  That's not going to be a
>> small change unfortunately :-(

> No, but it looks like a clear bug scenario and a clear resolution also.
> I'll start looking at it.

I'm on it already.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Rewrite the GiST insertion logic so that we don't need the post-recovery