Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitedde59d

Browse files
committed
Fix longstanding bug in HeapTupleSatisfiesVacuum().
HeapTupleSatisfiesVacuum() didn't properly discern betweenDELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have beeninserted in the current transaction and deleted in a abortedsubtransaction of the current backend. At the very least that causedproblems for CLUSTER and CREATE INDEX in transactions that hadaborting 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. Asimplemented this separatation can cause a behaviour change for rowsthat have been inserted and deleted in another, still running,transaction. HTSV will now return INSERT_IN_PROGRESS instead ofDELETE_IN_PROGRESS for those. That's both, more in line with the othervisibility routines and arguably more correct. The latter because aINSERT_IN_PROGRESS will make callers look at/wait for xmin, instead ofxmax.The only current caller where that's possibly worse than the oldbehaviour is heap_prune_chain() which now won't mark the page asprunable if a row has concurrently been inserted and deleted. That'sharmless enough.As a cautionary measure also insert a interrupt check before the gotosin IndexBuildHeapScan() that lead to the uninterruptible loop. Thereare other possible causes, like a row that several sessions try toupdate and all fail, for repeated loops and the cost of doing so inthe retry case is low.As this bug goes back all the way to the introduction ofsubtransactions in573a71a backpatch to all supported releases.Reported-By: Sandro Santilli
1 parent8dc90b9 commitedde59d

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
@@ -2334,6 +2334,7 @@ IndexBuildHeapScan(Relation heapRelation,
23342334
*/
23352335
LockBuffer(scan->rs_cbuf,BUFFER_LOCK_UNLOCK);
23362336
XactLockTableWait(xwait);
2337+
CHECK_FOR_INTERRUPTS();
23372338
gotorecheck;
23382339
}
23392340
}
@@ -2380,6 +2381,7 @@ IndexBuildHeapScan(Relation heapRelation,
23802381
*/
23812382
LockBuffer(scan->rs_cbuf,BUFFER_LOCK_UNLOCK);
23822383
XactLockTableWait(xwait);
2384+
CHECK_FOR_INTERRUPTS();
23832385
gotorecheck;
23842386
}
23852387

‎src/backend/utils/time/tqual.c

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1342,7 +1342,7 @@ HeapTupleSatisfiesVacuum(HeapTupleHeader tuple, TransactionId OldestXmin,
13421342
returnHEAPTUPLE_DEAD;
13431343
}
13441344
}
1345-
elseif (TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple)))
1345+
elseif (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple)))
13461346
{
13471347
if (tuple->t_infomask&HEAP_XMAX_INVALID)/* xid invalid */
13481348
returnHEAPTUPLE_INSERT_IN_PROGRESS;
@@ -1351,7 +1351,22 @@ HeapTupleSatisfiesVacuum(HeapTupleHeader tuple, TransactionId OldestXmin,
13511351
HeapTupleHeaderIsOnlyLocked(tuple))
13521352
returnHEAPTUPLE_INSERT_IN_PROGRESS;
13531353
/* inserted and then deleted by same xact */
1354-
returnHEAPTUPLE_DELETE_IN_PROGRESS;
1354+
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tuple)))
1355+
returnHEAPTUPLE_DELETE_IN_PROGRESS;
1356+
/* deleting subtransaction must have aborted */
1357+
returnHEAPTUPLE_INSERT_IN_PROGRESS;
1358+
}
1359+
elseif (TransactionIdIsInProgress(HeapTupleHeaderGetXmin(tuple)))
1360+
{
1361+
/*
1362+
* It'd be possible to discern between INSERT/DELETE in progress
1363+
* here by looking at xmax - but that doesn't seem beneficial for
1364+
* the majority of callers and even detrimental for some. We'd
1365+
* rather have callers look at/wait for xmin than xmax. It's
1366+
* always correct to return INSERT_IN_PROGRESS because that's
1367+
* what's happening from the view of other backends.
1368+
*/
1369+
returnHEAPTUPLE_INSERT_IN_PROGRESS;
13551370
}
13561371
elseif (TransactionIdDidCommit(HeapTupleHeaderGetXmin(tuple)))
13571372
SetHintBits(tuple,buffer,HEAP_XMIN_COMMITTED,

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp