Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

On Tue, Oct 17, 2017 at 6:02 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Robert Haas wrote:
>> I haven't really followed this thread in depth, but I'm very nervous
>> about the idea that we should ever be examining the raw-xmin of a
>> tuple that has been marked HEAP_XMIN_FROZEN for anything other than
>> forensic purposes.
>
> Yeah, me too. If you see another way to fix the problem, let's discuss
> it.

Well, I guess what I don't understand is, suppose we have a HOT chain
that looks like this, where [x,y] denotes a tuple with an xmin of x
and an xmax of y.

[a,b]->[b,c]->[c,d]

If b is eligible to be frozen, then b is committed and all-visible,
which means that the [a,b] tuple should be pruned altogether. IOW, I
don't think that a non-root tuple should ever have a frozen xmin; if
that happens, I think we've already screwed up. So I don't quite
understand how this problem arises in the first place.

I think that the way we are supposed to be guaranteeing this is to
first prune the page and then freeze it. If we ever freeze without
first pruning, I think that's a bug. Now it could be that the problem
is that there's a race: after we prune the page, somehow the xmin
horizon advances before we freeze. But that also seems like something
that shouldn't happen - our notion of the freeze threshold should be
frozen at the beginning of the scan and should not advance, and it
should be prior to our freeze horizon, which could be allowed to
advance but not retreat in the course of the scan.

Apologies if this is stupid; please clue me on what I'm missing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company