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

Commite8528a8

Browse files
committed
Fix deadlock at startup, if max_prepared_transactions is too small.
When the startup process recovers transactions by scanning pg_twophasedirectory, it should clear MyLockedGxact after it's done processing eachtransaction. Like we do during normal operation, at PREPARE TRANSACTION.Otherwise, if the startup process exits due to an error, it will try toclear the locking_backend field of the last recovered transaction. That'susually harmless, but if the error happens in MarkAsPreparing, whileholding TwoPhaseStateLock, the shmem-exit hook will try to acquireTwoPhaseStateLock again, and deadlock with itself.This fixes bug #13128 reported by Grant McAlister. The bug was introducedby commitbb38fb0, so backpatch to all supported versions like thatcommit.
1 parent42f5227 commite8528a8

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

‎src/backend/access/transam/twophase.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2018,6 +2018,12 @@ RecoverPreparedTransactions(void)
20182018
if (InHotStandby)
20192019
StandbyReleaseLockTree(xid,hdr->nsubxacts,subxids);
20202020

2021+
/*
2022+
* We're done with recovering this transaction. Clear MyLockedGxact,
2023+
* like we do in PrepareTransaction() during normal operation.
2024+
*/
2025+
PostPrepare_Twophase();
2026+
20212027
pfree(buf);
20222028
}
20232029
}

0 commit comments

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