upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-06-21 06:29:06 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Make StandbyAcquireAccessExclusiveLock() more resilent with OOMs

Browse source 
In StandbyReleaseXidEntryLocks, a failure in acquiring a lock with
LockAcquire() due to an out-of-memory problem would lead to an
inconsistency with the lock state cached in the startup process,
impacting the list of RecoveryLockXidEntrys.  The code is updated here
so as the cached state is updated once the lock is acquired.

This problem is unlikely going to happen in practice.  Even if it were
to show up, it would translate to a LOG message for non-assert builds
(assertion failure otherwise), so no backpatch is done.  This commit is
in the same spirit as 29fb598b9c, with a problem emulated by injecting
random failures for allocations.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>
Discussion: https://postgr.es/m/e77acaac-a1b3-40b3-99ee-5769b4e453e4@gmail.com
This commit is contained in:
Michael Paquier 2026-06-20 15:00:40 +09:00
parent f25a07b2d9
commit b85f9c00fb
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
src/backend/storage/ipc/standby.c
View file

@ -1019,14 +1019,14 @@ StandbyAcquireAccessExclusiveLock(TransactionId xid, Oid dbOid, Oid relOid)
lockentry = hash_search(RecoveryLockHash, &key, HASH_ENTER, &found);
if (!found)
{
/* It's new, so link it into the XID's list ... */
lockentry->next = xidentry->head;
xidentry->head = lockentry;
/* ... and acquire the lock locally. */
/* First, acquire the lock ... */
SET_LOCKTAG_RELATION(locktag, dbOid, relOid);
(void) LockAcquire(&locktag, AccessExclusiveLock, true, false);
/* ... and then, as it is new, link it into the XID's list. */
lockentry->next = xidentry->head;
xidentry->head = lockentry;
}
}