Re: snapshot too old, configured by time - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: snapshot too old, configured by time
Date
Msg-id CACjxUsNpPgH1-bG1tX0zdVYNG2oWtehvdog+OY8LEC_dek8=EQ@mail.gmail.com
Whole thread Raw
In response to Re: snapshot too old, configured by time  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: snapshot too old, configured by time
List pgsql-hackers
On Mon, Apr 18, 2016 at 8:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Surely there was another way to get a similar end result without
> mucking with things at the level of BufferGetPage.

To get the feature that some customers have been demanding, a check
has to be made somewhere near where any page is read in a scan.  It
didn't take me long in working on this to notice that grepping for
BufferGetPage() calls was a good way to find candidate spots to
insert the check (even if only 7% of BufferGetPage() calls need to
be followed by such a check) -- but the BufferGetPage() itself
clearly does *not* need to be modified to implement the feature.

We could:

(1) Add calls to a check function where needed, and just document
that addition of a BufferGetPage() call should be considered a clue
that a new check might be needed.  (original plan)

(2) Replace the 7% of the BufferGetPage() calls that need to check
the age of the snapshot with something that wraps the two function
calls, and does nothing but call one and then the other.  (favored
by Michael)

(3) Add parameters to BufferGetPage() to specify whether the check
is needed and provide sufficient information to perform the check
if it is.  (current master)

(4) Replace BufferGetPage() with some other function name having
the characteristics of (3) to minimize back-patch pain.
(grudgingly favored by Álvaro)

(5) Revert from community code, leaving it as an EDB value-add
Advanced Server feature.

Does someone see another (better) alternative?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Parser extensions (maybe for 10?)
Next
From: Pavel Stehule
Date:
Subject: Re: Relax requirement for INTO with SELECT in pl/pgsql