Re: Unexpected behavior after OOM errors

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unexpected behavior after OOM errors
Date: 2026-06-19 11:12:47
Message-ID: ajUkLyWHxCeFVop_@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-06-19 12:05:32 Re: [Bug][patch]: After dropping the last label from a property graph element, invoking pg_get_propgraphdef() triggers an assertion failure
Previous Message Jeyaprakash Rajamani 2026-06-19 09:34:00 Re: Performance Degradation (Table becomes bloat) During Repeated Bulk UPDATE Operations