Re: ERROR: found unexpected null value in index
От | Andres Freund |
---|---|
Тема | Re: ERROR: found unexpected null value in index |
Дата | |
Msg-id | FB9B6E43-B722-4291-A97A-2BF240A312E5@anarazel.de обсуждение исходный текст |
Ответ на | Re: ERROR: found unexpected null value in index (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ERROR: found unexpected null value in index
|
Список | 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 deadrows, 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 visibilitylater, 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 alwayshave all the information we need? Andres Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-bugs по дате отправления: