From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:08:42 |
Message-ID: | CAH2-Wz=MAO7L_YEQhOg2yK41L2-Zk9=MCe6QJkkGRwhfihLkRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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?
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-07-10 23:29:06 | Re: ERROR: found unexpected null value in index |
Previous Message | Tom Lane | 2019-07-10 22:26:29 | Re: ERROR: found unexpected null value in index |