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

Commit8f0de71

Browse files
committed
Don't ignore locktable-full failures in StandbyAcquireAccessExclusiveLock.
Commit37c5486 removed the code in StandbyAcquireAccessExclusiveLockthat checked the return value of LockAcquireExtended. That created abug, because it's still passing reportMemoryError = false toLockAcquireExtended, meaning that LOCKACQUIRE_NOT_AVAIL will be returnedif we're out of shared memory for the lock table.In such a situation, the startup process would believe it had acquired anexclusive lock even though it hadn't, with potentially dire consequences.To fix, just drop the use of reportMemoryError = false, which allows usto simplify the call into a plain LockAcquire(). It's unclear that thelocktable-full situation arises often enough that it's worth having abetter recovery method than crash-and-restart. (I strongly suspect thatthe only reason the code path existed at all was that it was relativelysimple to do in the pre-37c54863c implementation. But now it's not.)LockAcquireExtended's reportMemoryError parameter is now dead code andcould be removed. I refrained from doing so, however, because therewas some interest in resurrecting the behavior if we do get reports oflocktable-full failures in the field. Also, it seems unwise to removethe parameter concurrently with shipping commitf868a81, which added aparameter; if there are any third-party callers of LockAcquireExtended,we want them to get a wrong-number-of-parameters compile error ratherthan a possibly-silent misinterpretation of its last parameter.Back-patch to 9.6 where the bug was introduced.Discussion:https://postgr.es/m/6202.1536359835@sss.pgh.pa.us
1 parent2a63683 commit8f0de71

File tree

2 files changed

+8
-7
lines changed

2 files changed

+8
-7
lines changed

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

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -661,8 +661,7 @@ StandbyAcquireAccessExclusiveLock(TransactionId xid, Oid dbOid, Oid relOid)
661661

662662
SET_LOCKTAG_RELATION(locktag,newlock->dbOid,newlock->relOid);
663663

664-
(void)LockAcquireExtended(&locktag,AccessExclusiveLock, true, false,
665-
false,NULL);
664+
(void)LockAcquire(&locktag,AccessExclusiveLock, true, false);
666665
}
667666

668667
staticvoid

‎src/backend/storage/lmgr/lock.c

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -693,11 +693,13 @@ LockAcquire(const LOCKTAG *locktag,
693693
/*
694694
* LockAcquireExtended - allows us to specify additional options
695695
*
696-
* reportMemoryError specifies whether a lock request that fills the
697-
* lock table should generate an ERROR or not. This allows a priority
698-
* caller to note that the lock table is full and then begin taking
699-
* extreme action to reduce the number of other lock holders before
700-
* retrying the action.
696+
* reportMemoryError specifies whether a lock request that fills the lock
697+
* table should generate an ERROR or not. Passing "false" allows the caller
698+
* to attempt to recover from lock-table-full situations, perhaps by forcibly
699+
* cancelling other lock holders and then retrying. Note, however, that the
700+
* return code for that is LOCKACQUIRE_NOT_AVAIL, so that it's unsafe to use
701+
* in combination with dontWait = true, as the cause of failure couldn't be
702+
* distinguished.
701703
*
702704
* If locallockp isn't NULL, *locallockp receives a pointer to the LOCALLOCK
703705
* table entry if a lock is successfully acquired, or NULL if not.

0 commit comments

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