Re: Unexpected behavior after OOM errors
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-19T11:12:47Z
Lists: pgsql-hackers
On Fri, Jun 19, 2026 at 09:18:03AM +0200, Matthias van de Meent wrote: > On Fri, 19 Jun 2026 at 01:55, Michael Paquier <michael@paquier.xyz> wrote: >> We don't ERROR when failing to register a syscache/relcache callback, >> we FATAL if we reach one of the thresholds. > > Ah, thanks for correcting me. I'm not sure why I had ERROR in mind, > but you're obviously correct. Your patch v2 LGTM. Cool, thanks. >> Reaching these thresholds >> points to me to a programming error anyway, so these should not matter >> in the field. > > I don't think that's (necessarily) correct. These callbacks are > accessible to extensions, and if you load sufficiently many of those > you could still run out of slots even if each extension stayed well > within a reasonable threshold. Sure, but then the only way to get out of the problem is to patch the backend so there are more slots available. At the end, when it comes to core (and there should be some margin anyway), I am not really worried. -- Michael
Commits
-
Make type cache initialization more resilient on re-entry after OOM
- 73dab12719ee 19 (unreleased) landed
-
Make StandbyAcquireAccessExclusiveLock() more resilent with OOMs
- b85f9c00fb88 19 (unreleased) landed
-
Make GetSnapshotData() more resilient on out-of-memory errors
- 29fb598b9cad 19 (unreleased) landed