8000 Fix longstanding bug in HeapTupleSatisfiesVacuum(). · MattPerron/postgres@80d45ae · GitHub
[go: up one dir, main page]

Skip to content

Commit 80d45ae

Browse files
committed
Fix longstanding bug in HeapTupleSatisfiesVacuum().
HeapTupleSatisfiesVacuum() didn't properly discern between DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been inserted in the current transaction and deleted in a aborted subtransaction of the current backend. At the very least that caused problems for CLUSTER and CREATE INDEX in transactions that had aborting subtransactions producing rows, leading to warnings like: WARNING: concurrent delete in progress within table "..." possibly in an endless, uninterruptible, loop. Instead of treating *InProgress xmins the same as *IsCurrent ones, treat them as being distinct like the other visibility routines. As implemented this separatation can cause a behaviour change for rows that have been inserted and deleted in another, still running, transaction. HTSV will now return INSERT_IN_PROGRESS instead of DELETE_IN_PROGRESS for those. That's both, more in line with the other visibility routines and arguably more correct. The latter because a INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of xmax. The only current caller where that's possibly worse than the old behaviour is heap_prune_chain() which now won't mark the page as prunable if a row has concurrently been inserted and deleted. That's harmless enough. As a cautionary measure also insert a interrupt check before the gotos in IndexBuildHeapScan() that lead to the uninterruptible loop. There are other possible causes, like a row that several sessions try to update and all fail, for repeated loops and the cost of doing so in the retry case is low. As this bug goes back all the way to the introduction of subtransactions in 573a71a backpatch to all supported releases. Reported-By: Sandro Santilli
1 parent ae41bb4 commit 80d45ae

File tree

2 files changed

+19
-2
lines changed

2 files changed

+19
-2
lines changed

src/backend/catalog/index.c

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1711,6 +1711,7 @@ IndexBuildHeapScan(Relation heapRelation,
17111711

17121712
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
17131713
XactLockTableWait(xwait);
1714+
CHECK_FOR_INTERRUPTS();
17141715
goto recheck;
17151716
}
17161717
}
@@ -1743,6 +1744,7 @@ IndexBuildHeapScan(Relation heapRelation,
17431744

17441745
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
17451746
XactLockTableWait(xwait);
1747+
CHECK_FOR_INTERRUPTS();
17461748
goto recheck;
17471749
}
17481750

src/backend/utils/time/tqual.c

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1099,14 +1099,29 @@ HeapTupleSatisfiesVacuum(HeapTupleHeader tuple, TransactionId OldestXmin,
10991099
return HEAPTUPLE_DEAD;
11001100
}
11011101
}
1102-
else if (TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple)))
1102+
else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple)))
11031103
{
11041104
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
11051105
return HEAPTUPLE_INSERT_IN_PROGRESS;
11061106
if (tuple->t_infomask & HEAP_IS_LOCKED)
11071107
return HEAPTUPLE_INSERT_IN_PROGRESS;
11081108
/* inserted and then deleted by same xact */
1109-
return HEAPTUPLE_DELETE_IN_PROGRESS;
1109+
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)))
1110+
return HEAPTUPLE_DELETE_IN_PROGRESS;
1111+
/* deleting subtransaction must have aborted */
1112+
return HEAPTUPLE_INSERT_IN_PROGRESS;
1113+
}
1114+
else if (TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple)))
1115+
{
1116+
/*
1117+
* It'd be possible to discern between INSERT/DELETE in progress
1118+
* here by looking at xmax - but that doesn't seem beneficial for
1119+
* the majority of callers and even detrimental for some. We'd
1120+
* rather have callers look at/wait for xmin than xmax. It's
1121+
* always correct to return INSERT_IN_PROGRESS because that's
1122+
* what's happening from the view of other backends.
1123+
*/
1124+
return HEAPTUPLE_INSERT_IN_PROGRESS;
11101125
}
11111126
else if (TransactionIdDidCommit(HeapTupleHeaderGetXmin(tuple)))
11121127
SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,

0 commit comments

Comments
 (0)
0