Re: old_snapshot_threshold's interaction with hash index - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: old_snapshot_threshold's interaction with hash index
Date
Msg-id 20160503154505.GC27541@momjian.us
Whole thread Raw
In response to Re: old_snapshot_threshold's interaction with hash index  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: old_snapshot_threshold's interaction with hash index
List pgsql-hackers
On Mon, May  2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote:
> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >>
> >> Currently we do the test for old snapshot (TestForOldSnapshot) for hash
> >> indexes while scanning them.  Does this test makes any sense for hash
> >> indexes considering LSN on hash index will always be zero (as hash indexes
> >> are not WAL-logged)?  It seems to me that PageLSN check in
> >> TestForOldSnapshot() will always return false which means that the error
> >> "snapshot too old" won't be generated for hash indexes.
> >>
> >> Am I missing something here, if not, then I think we need a way to
> >> prohibit pruning for hash indexes based on old_snapshot_threshold?
> >
> > What I mean to say here is prohibit pruning the relation which has hash
> > index based on old_snapshot_threshold.
> 
> Good spot; added to the open issues page.

Uh, I have no idea how this would be fixed if the PageLSN is zero.  Do
you?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Kevin Grittner
Date:
Subject: Re: old_snapshot_threshold's interaction with hash index