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

Commit0c99e71

Browse files
committed
Avoid duplicate XIDs at recovery when building initial snapshot
On a primary, sets of XLOG_RUNNING_XACTS records are generated on aperiodic basis to allow recovery to build the initial state oftransactions for a hot standby. The set of transaction IDs is createdby scanning all the entries in ProcArray. However it happens that itslogic never counted on the fact that two-phase transactions finishing toprepare can put ProcArray in a state where there are two entries withthe same transaction ID, one for the initial transaction which getscleared when prepare finishes, and a second, dummy, entry to track thatthe transaction is still running after prepare finishes. This wayensures a continuous presence of the transaction so as callers of forexample TransactionIdIsInProgress() are always able to see it as alive.So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phasetransaction finishes to prepare, the record can finish with duplicatedXIDs, which is a state expected by design. If this record gets appliedon a standby to initial its recovery state, then it would simply fail,so the odds of facing this failure are very low in practice. It wouldbe tempting to change the generation of XLOG_RUNNING_XACTS so asduplicates are removed on the source, but this requires to hold onProcArrayLock for longer and this would impact all workloads,particularly those using heavily two-phase transactions.XLOG_RUNNING_XACTS is also actually used only to initialize the standbystate at recovery, so instead the solution is taken to discardduplicates when applying the initial snapshot.Diagnosed-by: Konstantin KnizhnikAuthor: Michael PaquierDiscussion:https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ruBackpatch-through: 9.3
1 parentfb583c8 commit0c99e71

File tree

1 file changed

+19
-2
lines changed

1 file changed

+19
-2
lines changed

‎src/backend/storage/ipc/procarray.c

Lines changed: 19 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -651,10 +651,21 @@ ProcArrayApplyRecoveryInfo(RunningTransactions running)
651651
qsort(xids,nxids,sizeof(TransactionId),xidComparator);
652652

653653
/*
654-
* Add the sorted snapshot into KnownAssignedXids
654+
* Add the sorted snapshot into KnownAssignedXids. The running-xacts
655+
* snapshot may include duplicated xids because of prepared
656+
* transactions, so ignore them.
655657
*/
656658
for (i=0;i<nxids;i++)
659+
{
660+
if (i>0&&TransactionIdEquals(xids[i-1],xids[i]))
661+
{
662+
elog(DEBUG1,
663+
"found duplicated transaction %u for KnownAssignedXids insertion",
664+
xids[i]);
665+
continue;
666+
}
657667
KnownAssignedXidsAdd(xids[i],xids[i], true);
668+
}
658669

659670
KnownAssignedXidsDisplay(trace_recovery(DEBUG3));
660671
}
@@ -1604,7 +1615,8 @@ ProcArrayInstallImportedXmin(TransactionId xmin, TransactionId sourcexid)
16041615
* GetRunningTransactionData -- returns information about running transactions.
16051616
*
16061617
* Similar to GetSnapshotData but returns more information. We include
1607-
* all PGXACTs with an assigned TransactionId, even VACUUM processes.
1618+
* all PGXACTs with an assigned TransactionId, even VACUUM processes and
1619+
* prepared transactions.
16081620
*
16091621
* We acquire XidGenLock, but the caller is responsible for releasing it.
16101622
* This ensures that no new XIDs enter the proc array until the caller has
@@ -1616,6 +1628,11 @@ ProcArrayInstallImportedXmin(TransactionId xmin, TransactionId sourcexid)
16161628
* This is never executed during recovery so there is no need to look at
16171629
* KnownAssignedXids.
16181630
*
1631+
* Dummy PGXACTs from prepared transaction are included, meaning that this
1632+
* may return entries with duplicated TransactionId values coming from
1633+
* transaction finishing to prepare. Nothing is done about duplicated
1634+
* entries here to not hold on ProcArrayLock more than necessary.
1635+
*
16191636
* We don't worry about updating other counters, we want to keep this as
16201637
* simple as possible and leave GetSnapshotData() as the primary code for
16211638
* that bookkeeping.

0 commit comments

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