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 CAM3SWZTBFdosbz_0e8QtpY5dRTK6ThrZ_+Pe0CY21dRGVT8oJQ@mail.gmail.com
Whole thread Raw
In response to Re: snapshot too old, configured by time  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: snapshot too old, configured by time
Re: snapshot too old, configured by time
List pgsql-hackers
On Thu, Mar 17, 2016 at 2:15 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> New patch just to merge in recent commits -- it was starting to
> show some bit-rot.  Tests folded in with main patch.

I haven't read the patch, but I wonder: What are the implications here
for B-Tree page recycling by VACUUM? I know that you understand this
topic well, so I don't assume that you didn't address it.

Offhand, I imagine that there'd be some special considerations. Why is
it okay that an index scan could land on a deleted page with no
interlock against VACUUM's page recycling? Or, what prevents that from
happening in the first place?

I worry that something weird could happen there. For example, perhaps
the page LSN on what is actually a newly recycled page could be set
such that the backend following a stale right spuriously raises a
"snapshot too old" error.

I suggest you consider making amcheck [1] a part of your testing
strategy. I think that this patch is a good idea, and I'd be happy to
take feedback from you on how to make amcheck more effective for
testing this patch in particular.

[1] https://commitfest.postgresql.org/9/561/
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: multivariate statistics v14
Next
From: Peter Geoghegan
Date:
Subject: Re: snapshot too old, configured by time