| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Make StandbyAcquireAccessExclusiveLock() more resilent with OOMs |
| Date: | 2026-06-20 06:02:44 |
| Message-ID: | E1waomy-0016NC-2T@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Make StandbyAcquireAccessExclusiveLock() more resilent with OOMs
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 29fb598b9cad, with a problem emulated by injecting
random failures for allocations.
Reported-by: Alexander Lakhin <exclusion(at)gmail(dot)com>
Author: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Discussion: https://postgr.es/m/e77acaac-a1b3-40b3-99ee-5769b4e453e4@gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/b85f9c00fb8822eb2142c347ce529f651dbef178
Modified Files
--------------
src/backend/storage/ipc/standby.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-06-20 07:29:45 | pgsql: Make type cache initialization more resilient on re-entry after |
| Previous Message | Tom Lane | 2026-06-19 16:52:16 | pgsql: Make pg_mkdir_p() tolerant of a concurrent directory creation. |