From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Mats Kindahl <mats(at)timescale(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, daniel(at)yesql(dot)se, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Crash during backend start when low on memory |
Date: | 2023-02-05 23:18:14 |
Message-ID: | 20230205231814.47pzdd5qqmvoq3pp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-02-06 01:51:30 | BUG #17772: small glitch with autocompletion on CREATE DATABASE |
Previous Message | Mats Kindahl | 2023-02-05 21:00:20 | Re: Crash during backend start when low on memory |