From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Wood, Dan" <hexpert(at)amazon(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Wong, Yi Wen" <yiwong(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Date: | 2017-10-06 18:07:45 |
Message-ID: | CAH2-Wzk7paqsOQexUDiukuZMK08r-=MuOrAtntn-8jZ75mo5rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, Oct 6, 2017 at 7:59 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> By the way, I still wonder if there's any way for a new tuple to get
> inserted in the place where a HOT redirect would be pointing to, and
> have it be marked as Frozen, where the old redirect contains a
> non-invalid Xmax. I tried to think of a way for that to happen, but
> couldn't think of anything.
>
> What I imagine is a sequence like this:
>
> 1. insert a tuple
> 2. HOT-update a tuple
> 3. prune the page, making lp 1 be a redirect (lp 2 is the new tuple)
> 4. start transaction
> 5. HOT-update the tuple again, creating HOT in lp 3
> 6. abort transaction (leaving aborted update in lp 3)
> 7. somehow remove tuple from lp 3, make slot available
> 8. new transaction comes along, inserts tuple in lp 3
> 9. somebody freezes tuple in lp3 (???)
>
> Then we follow the HOT chain, see that Xmin=2 in lp3 and conclude that
> the tuple is part of the chain because of an xid "match".
>
> Basically from step 7 onwards I don't think this is possible, but maybe
> I'm just blind.
For the record, I also think that this is impossible, in part because
pruning requires a cleanup buffer lock (and because HOT chains cannot
span pages). I wouldn't say that I am 100% confident about this,
though.
BTW, is this comment block that appears above
heap_prepare_freeze_tuple() now obsolete, following 20b65522 (and
maybe much earlier commits)?
* NB: It is not enough to set hint bits to indicate something is
* committed/invalid -- they might not be set on a standby, or after crash
* recovery. We really need to remove old xids.
*/
We WAL-log setting hint bits during freezing now, iff tuple xmin is
before the Xid cutoff and tuple is a heap-only tuple.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-10-06 18:28:47 | pgsql: Fix intra-query memory leakage in nodeProjectSet.c. |
Previous Message | Robert Haas | 2017-10-06 18:01:49 | Re: pgsql: Basic partition-wise join functionality. |
From | Date | Subject | |
---|---|---|---|
Next Message | Maksim Milyutin | 2017-10-06 18:18:14 | Re: Proposal: Local indexes for partitioned table |
Previous Message | Alvaro Herrera | 2017-10-06 17:49:56 | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |