Re: No Callbacks on FATAL - Mailing list pgsql-hackers

From Andres Freund
Subject Re: No Callbacks on FATAL
Date
Msg-id 20230113175454.ct2o3jk63bw6wipj@awork3.anarazel.de
Whole thread Raw
In response to Re: No Callbacks on FATAL  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi,

On 2023-01-13 16:14:11 +0300, Aleksander Alekseev wrote:
> > > Hm? MemoryContextDelete() unconditionally calls the
> > > callbacks. ShutdownPostgres() calls AbortOutOfAnyTransaction(). So if there's
> > > an ongoing transaction, we'll call the reset callbacks on TopMemoryContext and
> > > its children.
> >
> > Hmm ... I'd forgotten that we'd reach AbortOutOfAnyTransaction in
> > the FATAL code path.  It does seem like any memory contexts below
> > TopTransactionContext ought to get cleaned up then.
> 
> I wonder if this is a desired behavior. FATAL means a critical error
> local to a given backend, but not affecting shared memory, right? Is
> it generally safe to execute context memory callbacks having a FATAL
> error?

We need to roll back the in-progress transaction, otherwise we'd be in
trouble. Some resets are part of that. If the error actually corrupted local
state badly enough to break the transaction machinery, we'd need to PANIC out.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jelte Fennema
Date:
Subject: Re: [EXTERNAL] Re: Support load balancing in libpq
Next
From: Nathan Bossart
Date:
Subject: Re: PL/Python: Fix return in the middle of PG_TRY() block.