From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ERROR: found unexpected null value in index |
Date: | 2019-07-10 23:29:06 |
Message-ID: | 21234.1562801346@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Wed, Jul 10, 2019 at 3:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?
Index-only scans already have the LP_DEAD fast path (don't return value)
and the all_visible fast path (always return value), and otherwise they
do a heap visit. If we can use a custom visibility test in the heap
visit and not muck up the opportunity to set LP_DEAD when relevant, then
it seems like using the IOS code path will do exactly what we want.
Otherwise some finagling might be necessary. But it still might be
cleaner than directly looking at HOT-update status.
I'll take a look at that tomorrow if nobody beats me to it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-07-10 23:58:30 | Re: BUG #15888: Bogus "idle in transaction" state for logical decoding client after creating a slot |
Previous Message | Peter Geoghegan | 2019-07-10 23:08:42 | Re: ERROR: found unexpected null value in index |