Re: Latches vs lwlock contention
От | Peter Eisentraut |
---|---|
Тема | Re: Latches vs lwlock contention |
Дата | |
Msg-id | cc2996ee-3df7-d2ec-0a00-aee7cab0ccbc@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Latches vs lwlock contention (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Latches vs lwlock contention
|
Список | 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 по дате отправления: