Re: No Callbacks on FATAL

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ed Behn <ed(at)behn(dot)us>
Subject: Re: No Callbacks on FATAL
Date: 2023-01-13 13:14:11
Message-ID: CAJ7c6TMYwE-oVLh3DZWroj-XdSKOooGx=GKuW4MkR3iO6pL7Vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

> > 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?

> As you say, we really need more details to see what's happening here.

Yep, minimal steps to reproduce the issue would be much appreciated!

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2023-01-13 13:55:31 BF animal malleefowl reported an failure in 001_password.pl
Previous Message Aleksander Alekseev 2023-01-13 13:02:00 Re: PG11 to PG14 Migration Slowness