From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |
Date: | 2017-10-18 21:52:41 |
Message-ID: | CAH2-Wz=Ez_ccNBLu+JG0xZ6TNmNkrEHro_AGq+C8B7TXqNa4sA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, Oct 18, 2017 at 1:54 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
Technically, we don't freeze the heap-only tuples here, because we
cannot. because freezing tuples renders them visible (we don't set
XMIN_FROZEN). Instead, we set hint bits with WAL-logging, on the
assumption that nobody will ever *need* to interrogate the clog -- see
commit 20b65522 from several weeks back. To be clear, this *does* mean
that hint bits stop being mere hints, which I find troubling.
I described these heap-only tuples as "logically frozen" over on the
"heap/SLRU verification, relfrozenxid cut-off, and freeze-the-dead
bug" thread, which is where I brought up my general concern.
> I think that the way we are supposed to be guaranteeing this is to
> first prune the page and then freeze it.
There is a race where we cannot prune the page, though. That's why we
had to revisit what I suppose was a tacit assumption, and address its
problems in the commit that started this thread (commit a5736bf7).
> 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.
It is not allowed retreat -- kind of. (Alvaro mentioned something in
passing about an *alternative* fix where it really was allowed to
retreat in the simplest sense [1], but I don't think that that's going
to happen.)
> Apologies if this is stupid; please clue me on what I'm missing.
I don't think that your questions are stupid at all. It intuitively
seems bad that xmin freezing is only something we can do to HOT root
and non-HOT tuples, while xmax freezing needs to happen to heap-only
tuples, as well as HOT root tuples and non-HOT tuples. But, as I said,
I'm still playing catch-up on MultiXacts, and I too feel like I might
still be missing important details.
[1] https://postgr.es/m/20171017100200.ruszi2c6qqwetce5@alvherre.pgsql
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-10-19 10:01:33 | pgsql: UCS_to_most.pl: Process encodings in sorted order |
Previous Message | Robert Haas | 2017-10-18 20:54:46 | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2017-10-18 22:00:12 | Re: Interest in a SECURITY DEFINER function current_user stack access mechanism? |
Previous Message | David G. Johnston | 2017-10-18 21:45:47 | Re: Interest in a SECURITY DEFINER function current_user stack access mechanism? |