Re: Latches vs lwlock contention

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Latches vs lwlock contention
Date: 2023-07-06 09:58:09
Message-ID: cc2996ee-3df7-d2ec-0a00-aee7cab0ccbc@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04.03.23 20:50, Thomas Munro wrote:
> Subject: [PATCH v3 1/6] Allow palloc_extended(NO_OOM) in critical sections.
>
> Commit 4a170ee9e0e banned palloc() and similar in critical sections, because an
> allocation failure would produce a panic. Make an exception for allocation
> with NULL on failure, for code that has a backup plan.

I suppose this assumes that out of memory is the only possible error
condition that we are concerned about for this?

For example, we sometimes see "invalid memory alloc request size" either
because of corrupted data or because code does things we didn't expect.
This would then possibly panic? Also, the realloc code paths
potentially do more work with possibly more error conditions, and/or
they error out right away because it's not supported by the context type.

Maybe this is all ok, but it would be good to make the assumptions more
explicit.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2023-07-06 10:07:02 Re: MarkGUCPrefixReserved() doesn't check all options
Previous Message Daniel Gustafsson 2023-07-06 09:57:07 Re: Make ON_ERROR_STOP stop on shell script failure