From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lowering the ever-growing heap->pd_lower |
Date: | 2021-03-09 22:10:26 |
Message-ID: | 2046794.1615327826@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>> On Mar 9, 2021, at 1:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So, to accept a patch that shortens the line pointer array, what we need
>> to do is verify that every such code path checks for an out-of-range
>> offset before trying to fetch the target line pointer.
> Much as Pavan asked [1], I'm curious how we wouldn't already be in trouble if such code exists? In such a scenario, what stops a dead line pointer from being reused (rather than garbage collected by this patch) prior to such hypothetical code using an outdated TID?
The line pointer very well *could* be re-used before the in-flight
reference gets to it. That's okay though, because whatever tuple now
occupies the TID would have to have xmin too new to match the snapshot
that such a reference is scanning with.
(Back when we had non-MVCC snapshots to contend with, a bunch of
additional arm-waving was needed to argue that such situations were
safe. Possibly the proposed change wouldn't have flown back then.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-09 22:11:33 | Re: Lowering the ever-growing heap->pd_lower |
Previous Message | Peter Geoghegan | 2021-03-09 21:54:17 | Re: Lowering the ever-growing heap->pd_lower |