Re: Crash during backend start when low on memory
От | Andres Freund |
---|---|
Тема | Re: Crash during backend start when low on memory |
Дата | |
Msg-id | 20230205231814.47pzdd5qqmvoq3pp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Crash during backend start when low on memory (Mats Kindahl <mats@timescale.com>) |
Ответы |
Re: Crash during backend start when low on memory
|
Список | pgsql-bugs |
Hi, On 2023-02-05 22:00:20 +0100, Mats Kindahl wrote: > Tom had some concerns about using PG_TRY() inside the postmaster > ServerLoop I don't think we gain anything in most of the places by using PG_TRY instead of a non-throwing allocations. The relevant is cooperating closely enough that just returning returning a failure indicator is sufficient. Note that that doesn't mean that palloc can't be used, see MCXT_ALLOC_NO_OOM. >, but I cannot see how that can cause problems since it is "just" > a setjmp() and longjmp(). It allocates a structure on the stack that > contains the values of the registers and the signal set; it is big, but not > exceedingly so. If somebody could enlighten me about if there are any > problems with this, I would be very grateful. If you aren't careful you end up with PG_exception_stack in a backend still pointing to that PG_TRY. Which means that an error during backend startup would jump into postmaster code. Which would not be good. Particularly because this is a bugfix we need to make the fix more minimal than the patches proposed so far. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: