Re: ERROR: found unexpected null value in index
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>,Manuel Rigger
<rigger.manuel@gmail.com>,PostgreSQL mailing lists
<pgsql-bugs@lists.postgresql.org>
Date: 2019-07-10T20:36:23Z
Lists: pgsql-bugs
Hi, On July 10, 2019 1:25:49 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Andres Freund <andres@anarazel.de> writes: >> On 2019-07-10 16:02:50 -0400, Tom Lane wrote: >>> Should we try to transpose some of this logic to below the AM API, >>> and if so, what should that look like? > >> I wonder if we could push this down into a separate type of >visibility >> (or maybe redefine NonVacuumable)? So that the scan wouldn't ever >> return them in the first place? It's a bit annoying to have a >visibility >> type that's perhaps best called "what selfuncs.c needs", but still >seams >> cleaner than having a separate callback? And the explanation for why >> that's possibly needed also seems to better belong inside the AMs. > >SnapshotNonVacuumable is already basically "what selfuncs.c needs" --- >nothing else is using it. So I wouldn't hesitate to redefine it if >that'd fix the problem. But it doesn't sound like a promising >approach. >The problem here isn't whether the heap tuple is live or dead, it's >whether it can be trusted to match the index entry. Well, if we defined i the snapshot semantics as "return rows that are not vacuumable and safe for selfuncs.c considerations" it seems like a visibility concern if you squint a tiny bit. It's a mostly checking for certain kinds of dead rows, after all. > Also, snapshot >checking isn't really below the AM API anyway is it? It is, imo. Scans callbacks are expected to only return visible rows. And if a tuple in a slot needs to be checked for visibility later, that goes through a callback. Don't see how you could otherwise make different non-pgheap storages work. >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. >We'd then need to make sure that the logic exploits btree's "killed >index entry" ability, so that dead extremal values are ignored as >much as possible. But that'd get us out of the broken-HOT-chain >problem. Hm, that doesn't sound like a trivial change. Not at my computer for 20min, so can't check rn, but does the index entry always have all the information we need? Andres Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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