Skip to content

Commit 3a135bd

Browse files
alvherrealvherre
committed
Fix freezing of a dead HOT-updated tuple
Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before HeapTupleSatisfiesVacuum tests them. This happens to activate the code that decides to freeze the tuple ... which resuscitates it, duplicating data. (This is especially bad if there's any unique constraints, because those are now internally violated due to the duplicate entries, though you won't know until you try to REINDEX or dump/restore the table.) One possible fix would be to simply skip doing anything to the tuple, and hope that the next HOT prune would remove it. But there is a problem: if the tuple is older than freeze horizon, this would leave an unfrozen XID behind, and if no HOT prune happens to clean it up before the containing pg_clog segment is truncated away, it'd later cause an error when the XID is looked up. Fix the problem by having the tuple freezing routines cope with the situation: don't freeze the tuple (and keep it dead). In the cases that the XID is older than the freeze age, set the HEAP_XMAX_COMMITTED flag so that there is no need to look up the XID in pg_clog later on. An isolation test is included, authored by Michael Paquier, loosely based on Daniel Wood's original reproducer. It only tests one particular scenario, though, not all the possible ways for this problem to surface; it be good to have a more reliable way to test this more fully, but it'd require more work. In message https://postgr.es/m/20170911140103.5akxptyrwgpc25bw@alvherre.pgsql I outlined another test case (more closely matching Dan Wood's) that exposed a few more ways for the problem to occur. Backpatch all the way back to 9.3, where this problem was introduced by multixact juggling. In branches 9.3 and 9.4, this includes a backpatch of commit e5ff9fefcd50 (of 9.5 era), since the original is not correctable without matching the coding pattern in 9.5 up. Reported-by: Daniel Wood Diagnosed-by: Daniel Wood Reviewed-by: Yi Wen Wong, Michaël Paquier Discussion: https://postgr.es/m/E5711E62-8FDF-4DCA-A888-C200BF6B5742@amazon.com
1 parent def03e4 commit 3a135bd

File tree

5 files changed

+179
-27
lines changed

5 files changed

+179
-27
lines changed

‎src/backend/access/heap/heapam.c

Lines changed: 40 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -6414,14 +6414,23 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
64146414
Assert(TransactionIdIsValid(xid));
64156415

64166416
/*
6417-
* If the xid is older than the cutoff, it has to have aborted,
6418-
* otherwise the tuple would have gotten pruned away.
6417+
* The updating transaction cannot possibly be still running, but
6418+
* verify whether it has committed, and request to set the
6419+
* COMMITTED flag if so. (We normally don't see any tuples in
6420+
* this state, because they are removed by page pruning before we
6421+
* try to freeze the page; but this can happen if the updating
6422+
* transaction commits after the page is pruned but before
6423+
* HeapTupleSatisfiesVacuum).
64196424
*/
64206425
if (TransactionIdPrecedes(xid, cutoff_xid))
64216426
{
6422-
Assert(!TransactionIdDidCommit(xid));
6423-
*flags |= FRM_INVALIDATE_XMAX;
6424-
xid = InvalidTransactionId; /* not strictly necessary */
6427+
if (TransactionIdDidCommit(xid))
6428+
*flags = FRM_MARK_COMMITTED | FRM_RETURN_IS_XID;
6429+
else
6430+
{
6431+
*flags |= FRM_INVALIDATE_XMAX;
6432+
xid = InvalidTransactionId; /* not strictly necessary */
6433+
}
64256434
}
64266435
else
64276436
{
@@ -6494,13 +6503,16 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
64946503
/*
64956504
* It's an update; should we keep it? If the transaction is known
64966505
* aborted or crashed then it's okay to ignore it, otherwise not.
6497-
* Note that an updater older than cutoff_xid cannot possibly be
6498-
* committed, because HeapTupleSatisfiesVacuum would have returned
6499-
* HEAPTUPLE_DEAD and we would not be trying to freeze the tuple.
65006506
*
65016507
* As with all tuple visibility routines, it's critical to test
65026508
* TransactionIdIsInProgress before TransactionIdDidCommit,
65036509
* because of race conditions explained in detail in tqual.c.
6510+
*
6511+
* We normally don't see committed updating transactions earlier
6512+
* than the cutoff xid, because they are removed by page pruning
6513+
* before we try to freeze the page; but it can happen if the
6514+
* updating transaction commits after the page is pruned but
6515+
* before HeapTupleSatisfiesVacuum.
65046516
*/
65056517
if (TransactionIdIsCurrentTransactionId(xid) ||
65066518
TransactionIdIsInProgress(xid))
@@ -6525,13 +6537,6 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
65256537
* we can ignore it.
65266538
*/
65276539

6528-
/*
6529-
* Since the tuple wasn't marked HEAPTUPLE_DEAD by vacuum, the
6530-
* update Xid cannot possibly be older than the xid cutoff.
6531-
*/
6532-
Assert(!TransactionIdIsValid(update_xid) ||
6533-
!TransactionIdPrecedes(update_xid, cutoff_xid));
6534-
65356540
/*
65366541
* If we determined that it's an Xid corresponding to an update
65376542
* that must be retained, additionally add it to the list of
@@ -6610,7 +6615,10 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
66106615
*
66116616
* It is assumed that the caller has checked the tuple with
66126617
* HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
6613-
* (else we should be removing the tuple, not freezing it).
6618+
* (else we should be removing the tuple, not freezing it). However, note
6619+
* that we don't remove HOT tuples even if they are dead, and it'd be incorrect
6620+
* to freeze them (because that would make them visible), so we mark them as
6621+
* update-committed, and needing further freezing later on.
66146622
*
66156623
* NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
66166624
* XID older than it could neither be running nor seen as running by any
@@ -6721,7 +6729,22 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
67216729
else if (TransactionIdIsNormal(xid))
67226730
{
67236731
if (TransactionIdPrecedes(xid, cutoff_xid))
6724-
freeze_xmax = true;
6732+
{
6733+
/*
6734+
* Must freeze regular XIDs older than the cutoff. We must not
6735+
* freeze a HOT-updated tuple, though; doing so would bring it
6736+
* back to life.
6737+
*/
6738+
if (HeapTupleHeaderIsHotUpdated(tuple))
6739+
{
6740+
frz->t_infomask |= HEAP_XMAX_COMMITTED;
6741+
totally_frozen = false;
6742+
changed = true;
6743+
/* must not freeze */
6744+
}
6745+
else
6746+
freeze_xmax = true;
6747+
}
67256748
else
67266749
totally_frozen = false;
67276750
}

‎src/backend/commands/vacuumlazy.c

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1984,17 +1984,17 @@ lazy_record_dead_tuple(LVRelStats *vacrelstats,
19841984
ItemPointer itemptr)
19851985
{
19861986
/*
1987-
* The array shouldn't overflow under normal behavior, but perhaps it
1988-
* could if we are given a really small maintenance_work_mem. In that
1989-
* case, just forget the last few tuples (we'll get 'em next time).
1987+
* The array must never overflow, since we rely on all deletable tuples
1988+
* being removed; inability to remove a tuple might cause an old XID to
1989+
* persist beyond the freeze limit, which could be disastrous later on.
19901990
*/
1991-
if (vacrelstats->num_dead_tuples < vacrelstats->max_dead_tuples)
1992-
{
1993-
vacrelstats->dead_tuples[vacrelstats->num_dead_tuples] = *itemptr;
1994-
vacrelstats->num_dead_tuples++;
1995-
pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
1996-
vacrelstats->num_dead_tuples);
1997-
}
1991+
if (vacrelstats->num_dead_tuples >= vacrelstats->max_dead_tuples)
1992+
elog(ERROR, "dead tuple array overflow");
1993+
1994+
vacrelstats->dead_tuples[vacrelstats->num_dead_tuples] = *itemptr;
1995+
vacrelstats->num_dead_tuples++;
1996+
pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
1997+
vacrelstats->num_dead_tuples);
19981998
}
19991999

20002000
/*

‎src/test/isolation/expected/freeze-the-dead.out

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
Parsed test spec with 2 sessions
2+
3+
starting permutation: s1_update s1_commit s1_vacuum s2_key_share s2_commit
4+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
5+
step s1_commit: COMMIT;
6+
step s1_vacuum: VACUUM FREEZE tab_freeze;
7+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
8+
id
9+
10+
3
11+
step s2_commit: COMMIT;
12+
13+
starting permutation: s1_update s1_commit s2_key_share s1_vacuum s2_commit
14+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
15+
step s1_commit: COMMIT;
16+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
17+
id
18+
19+
3
20+
step s1_vacuum: VACUUM FREEZE tab_freeze;
21+
step s2_commit: COMMIT;
22+
23+
starting permutation: s1_update s1_commit s2_key_share s2_commit s1_vacuum
24+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
25+
step s1_commit: COMMIT;
26+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
27+
id
28+
29+
3
30+
step s2_commit: COMMIT;
31+
step s1_vacuum: VACUUM FREEZE tab_freeze;
32+
33+
starting permutation: s1_update s2_key_share s1_commit s1_vacuum s2_commit
34+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
35+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
36+
id
37+
38+
3
39+
step s1_commit: COMMIT;
40+
step s1_vacuum: VACUUM FREEZE tab_freeze;
41+
step s2_commit: COMMIT;
42+
43+
starting permutation: s1_update s2_key_share s1_commit s2_commit s1_vacuum
44+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
45+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
46+
id
47+
48+
3
49+
step s1_commit: COMMIT;
50+
step s2_commit: COMMIT;
51+
step s1_vacuum: VACUUM FREEZE tab_freeze;
52+
53+
starting permutation: s1_update s2_key_share s2_commit s1_commit s1_vacuum
54+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
55+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
56+
id
57+
58+
3
59+
step s2_commit: COMMIT;
60+
step s1_commit: COMMIT;
61+
step s1_vacuum: VACUUM FREEZE tab_freeze;
62+
63+
starting permutation: s2_key_share s1_update s1_commit s1_vacuum s2_commit
64+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
65+
id
66+
67+
3
68+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
69+
step s1_commit: COMMIT;
70+
step s1_vacuum: VACUUM FREEZE tab_freeze;
71+
step s2_commit: COMMIT;
72+
73+
starting permutation: s2_key_share s1_update s1_commit s2_commit s1_vacuum
74+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
75+
id
76+
77+
3
78+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
79+
step s1_commit: COMMIT;
80+
step s2_commit: COMMIT;
81+
step s1_vacuum: VACUUM FREEZE tab_freeze;
82+
83+
starting permutation: s2_key_share s1_update s2_commit s1_commit s1_vacuum
84+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
85+
id
86+
87+
3
88+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
89+
step s2_commit: COMMIT;
90+
step s1_commit: COMMIT;
91+
step s1_vacuum: VACUUM FREEZE tab_freeze;
92+
93+
starting permutation: s2_key_share s2_commit s1_update s1_commit s1_vacuum
94+
step s2_key_share: SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE;
95+
id
96+
97+
3
98+
step s2_commit: COMMIT;
99+
step s1_update: UPDATE tab_freeze SET x = x + 1 WHERE id = 3;
100+
step s1_commit: COMMIT;
101+
step s1_vacuum: VACUUM FREEZE tab_freeze;

‎src/test/isolation/isolation_schedule

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,7 @@ test: update-locked-tuple
4141
test: propagate-lock-delete
4242
test: tuplelock-conflict
4343
test: tuplelock-update
44+
test: freeze-the-dead
4445
test: nowait
4546
test: nowait-2
4647
test: nowait-3

‎src/test/isolation/specs/freeze-the-dead.spec

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Test for interactions of tuple freezing with dead, as well as recently-dead
2+
# tuples using multixacts via FOR KEY SHARE.
3+
setup
4+
{
5+
CREATE TABLE tab_freeze (
6+
id int PRIMARY KEY,
7+
name char(3),
8+
x int);
9+
INSERT INTO tab_freeze VALUES (1, '111', 0);
10+
INSERT INTO tab_freeze VALUES (3, '333', 0);
11+
}
12+
13+
teardown
14+
{
15+
DROP TABLE tab_freeze;
16+
}
17+
18+
session "s1"
19+
setup { BEGIN; }
20+
step "s1_update" { UPDATE tab_freeze SET x = x + 1 WHERE id = 3; }
21+
step "s1_commit" { COMMIT; }
22+
step "s1_vacuum" { VACUUM FREEZE tab_freeze; }
23+
24+
session "s2"
25+
setup { BEGIN; }
26+
step "s2_key_share" { SELECT id FROM tab_freeze WHERE id = 3 FOR KEY SHARE; }
27+
step "s2_commit" { COMMIT; }

0 commit comments

Comments
 (0)