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 22:26:29 |
Message-ID: | 18788.1562797589@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 1:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-07-10 23:08:42 | Re: ERROR: found unexpected null value in index |
Previous Message | Peter Geoghegan | 2019-07-10 22:14:08 | Re: ERROR: found unexpected null value in index |