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

From Peter Geoghegan
Subject Re: snapshot too old, configured by time
Date
Msg-id CAM3SWZTPOoB51G7mXto+OPWGeJn3Lep_8OTduP+CjpW764rHkA@mail.gmail.com
Whole thread Raw
In response to Re: snapshot too old, configured by time  (Peter Geoghegan <pg@heroku.com>)
Responses Re: snapshot too old, configured by time
List pgsql-hackers
On Wed, Mar 30, 2016 at 12:21 PM, Peter Geoghegan <pg@heroku.com> wrote:
> Well, amcheck is a tool that in essence makes sure that B-Trees look
> structurally sound, and respect invariants like having every item on
> each page in logical order. That could catch a bug of the kind I just
> described, because it's quite likely that the recycled page would
> happen to have items that didn't comport with the ordering on the
> page.

I mean: didn't comport with the ordering of the last page "on the same
level" (but, due to this issue, maybe not actually on the same level).
We check if the first item on the "right page" (in actuality, due to
this bug, the new page image following a spurious early recycle) is
greater than or equal to the previous page (the page whose right-link
we followed) last item. On each level, everything should be in order
-- that's an invariant that (it is posited by me) we can safely check
with only an AccessShareLock.

Making the relation lock only a AccessShareLock is not just about
reducing the impact on production systems. It's also about making the
tool more effective at finding these kinds of transient races, with
subtle user-visible symptoms.

Again, I don't want to prejudice anyone against your patch, which I
haven't read.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: snapshot too old, configured by time
Next
From: David Rowley
Date:
Subject: Re: Combining Aggregates