Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "Wood, Dan" <hexpert@amazon.com>,
Michael Paquier <michael.paquier@gmail.com>, "Wong, Yi Wen" <yiwong@amazon.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-10-06T18:07:45Z
Lists: pgsql-hackers
On Fri, Oct 6, 2017 at 7:59 AM, Alvaro Herrera <alvherre@alvh.no-ip.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
Commits
-
Backport addition of rs_old_rel to rewriteheap's state.
- 152a56905658 9.3.21 landed
-
Perform a lot more sanity checks when freezing tuples.
- ed8e1aff6ace 9.4.16 landed
- d3044f8b0732 10.2 landed
- 986a9153b970 9.6.7 landed
- 94d1c88103ff 9.5.11 landed
- 4800f16a7ad0 9.3.21 landed
- 699bf7d05c68 11.0 landed
-
Revert bogus fixes of HOT-freezing bug
- c6764eb3aea6 11.0 landed
- f05ae2fa94b4 9.3.20 landed
- ef0339ee5dcf 9.4.15 landed
- b3888b60d3f0 9.5.10 landed
- 7a95966bc03c 10.1 landed
- 08ba67d596a1 9.6.6 landed
-
Fix traversal of half-frozen update chains
- a5736bf754c8 11.0 landed
- fc0df3bdafd6 9.5.10 landed
- d441cff14249 9.6.6 landed
- b052d524ca71 9.3.20 landed
- 8b6d85f2dc1e 9.4.15 landed
- 22576734b805 10.1 landed
-
Fix freezing of a dead HOT-updated tuple
- 46c35116ae1a 10.0 cited
- 20b655224249 11.0 cited
-
During index build, check and elog (not just Assert) for broken HOT chain.
- d70cf811f7dd 9.4.0 cited
-
Fix WAL replay of locking an updated tuple
- 6bfa88acd3df 9.4.0 cited
-
Change the way we mark tuples as frozen.
- 37484ad2aace 9.4.0 cited