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

  1. Make type cache initialization more resilient on re-entry after OOM

  2. Make StandbyAcquireAccessExclusiveLock() more resilent with OOMs

  3. Make GetSnapshotData() more resilient on out-of-memory errors