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

Commit5c5af32

Browse files
committed
Fix race between GetNewTransactionId and GetOldestActiveTransactionId.
The race condition goes like this:1. GetNewTransactionId advances nextXid e.g. from 100 to 1012. GetOldestActiveTransactionId reads the new nextXid, 1013. GetOldestActiveTransactionId loops through the proc array. There are no active XIDs there, so it returns 101 as the oldest active XID.4. GetNewTransactionid stores XID 100 to MyPgXact->xidSo, GetOldestActiveTransactionId returned XID 101, even though 100 onlyjust started and is surely still running.This would be hard to hit in practice, and even harder to spot any illeffect if it happens. GetOldestActiveTransactionId is only used whencreating a checkpoint in a master server, and the race condition can onlyhappen on an online checkpoint, as there are no backends running during ashutdown checkpoint. The oldestActiveXid value of an online checkpoint isonly used when starting up a hot standby server, to determine the startingpoint where pg_subtrans is initialized from. For the race condition tohappen, there must be no other XIDs in the proc array that would hold backthe oldest-active XID value, which means that the missed XID must be a toptransaction's XID. However, pg_subtrans is not used for top XIDs, so Ibelieve an off-by-one error is in fact inconsequential. Nevertheless, let'sfix it, as it's clearly wrong and the fix is simple.This has been wrong ever since hot standby was introduced, so backport toall supported versions.Discussion:https://www.postgresql.org/message-id/e7258662-82b6-7a45-56d4-99b337a32bf7@iki.fi
1 parentaea1a3f commit5c5af32

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

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

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1784,20 +1784,21 @@ GetOldestActiveTransactionId(void)
17841784

17851785
Assert(!RecoveryInProgress());
17861786

1787-
LWLockAcquire(ProcArrayLock,LW_SHARED);
1788-
17891787
/*
1790-
*It's okay to read nextXid without acquiring XidGenLock because (1) we
1791-
* assume TransactionIds can be read atomically and (2) we don't care if
1792-
*we get a slightly stale value. It can't be very stale anyway, because
1793-
*the LWLockAcquire above will have done any necessary memory
1794-
*interlocking.
1788+
*Read nextXid, as the upper bound of what's still active.
1789+
*
1790+
*Reading a TransactionId is atomic, but we must grab the lock to make
1791+
*sure that all XIDs < nextXid are already present in the proc array (or
1792+
*have already completed), when we spin over it.
17951793
*/
1794+
LWLockAcquire(XidGenLock,LW_SHARED);
17961795
oldestRunningXid=ShmemVariableCache->nextXid;
1796+
LWLockRelease(XidGenLock);
17971797

17981798
/*
17991799
* Spin over procArray collecting all xids and subxids.
18001800
*/
1801+
LWLockAcquire(ProcArrayLock,LW_SHARED);
18011802
for (index=0;index<arrayP->numProcs;index++)
18021803
{
18031804
intpgprocno=arrayP->pgprocnos[index];
@@ -1819,7 +1820,6 @@ GetOldestActiveTransactionId(void)
18191820
* smaller than oldestRunningXid
18201821
*/
18211822
}
1822-
18231823
LWLockRelease(ProcArrayLock);
18241824

18251825
returnoldestRunningXid;

0 commit comments

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