Re: Crash during backend start when low on memory

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

In response to

Responses

Browse pgsql-bugs by date

  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