Re: Latches vs lwlock contention - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Latches vs lwlock contention
Date
Msg-id cc2996ee-3df7-d2ec-0a00-aee7cab0ccbc@eisentraut.org
Whole thread Raw
In response to Re: Latches vs lwlock contention  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Latches vs lwlock contention
List 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.




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Make ON_ERROR_STOP stop on shell script failure
Next
From: Heikki Linnakangas
Date:
Subject: Re: MarkGUCPrefixReserved() doesn't check all options