Re: ERROR: found unexpected null value in index

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Manuel Rigger <rigger.manuel@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-07-10T23:08:42Z
Lists: pgsql-bugs
On Wed, Jul 10, 2019 at 3:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I was imagining it would still check the heap, if necessary, to verify
> that it'd found a tuple passing the given snapshot.

Not sure I follow. When or how would it not be necessary? Are you
merely referring to the simple case where the LP_DEAD bit is already
set for the item on the B-Tree leaf page?

> > Wasn't one of the goals of commit
> > 3ca930fc39c to make it more likely that extrema values would be killed
> > by get_actual_variable_range() scans, for the benefit of future
> > get_actual_variable_range() scans?
>
> Yes, and my point was that we still need that effect in some form.  But
> once we've found that there's a tuple that's "live enough" (for some
> definition of that) we could pull the actual data from the index not heap.

I think I follow -- that would do the right thing, without requiring
selfuncs.c to know about HOT, or some similar mechanism in an
alternative table AM.

-- 
Peter Geoghegan



Commits

  1. Fix get_actual_variable_range() to cope with broken HOT chains.

  2. Improve performance of get_actual_variable_range with recently-dead tuples.