Re: ERROR: found unexpected null value in index
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>,
Manuel Rigger <rigger.manuel@gmail.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-07-10T22:26:29Z
Lists: pgsql-bugs
Peter Geoghegan <pg@bowt.ie> writes: > On Wed, Jul 10, 2019 at 1:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I wonder if we'd be better off to switch over to using data directly >> from the index entry, rather than trying to recover it from the heap. > Maybe that problem has nothing to do with what you said, but I was > reminded of the fact that it's far from clear how effective > kill_prior_tuple actually is in the real world (i.e. with > concurrency). I guess that your suggestion would make it even less > likely that LP_DEAD hint bits would be set by > get_actual_variable_range() scans, because there would be no > opportunity to check the heap. I was imagining it would still check the heap, if necessary, to verify that it'd found a tuple passing the given snapshot. > 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. regards, tom lane
Commits
-
Fix get_actual_variable_range() to cope with broken HOT chains.
- d3751adcf14d 13.0 landed
- cee976c4e8c4 12.0 landed
- 5c1b7edc23a0 11.5 landed
-
Improve performance of get_actual_variable_range with recently-dead tuples.
- 3ca930fc39cc 11.0 cited