From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ed Behn <ed(at)behn(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: No Callbacks on FATAL |
Date: | 2023-01-12 00:57:13 |
Message-ID: | 20230112005713.zcv7akqqj5qaahx2@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-01-11 18:10:33 -0500, Tom Lane wrote:
> Ed Behn <ed(at)behn(dot)us> writes:
> > I'm using a callback function that is called when a memory context is
> > deleted to remove a temporary file. This works fine when the transaction
> > ends normally or raises an ERROR. However, when a FATAL event happens, the
> > callback is not run. Is this a bug or intended behaviour?
>
> It's intended behavior, and I seriously doubt that it ever worked
> differently.
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.
Of course that doesn't mean we'll delete all existing contexts...
> > It seems to me that callbacks should be run in the event of a FATAL event
> > in order to clean up any lingering issues.
>
> They'd be far more likely to cause issues than cure them. Or at least
> that's the design assumption. If you really need something here, put
> it in an on_proc_exit callback not a memory context callback.
Or, depending on the use case, a transaction callback.
It's really hard to know what precisely to suggest, without knowing a good bit
more about the intended usecase.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-01-12 00:59:14 | Re: low wal_retrieve_retry_interval causes missed signals on Windows |
Previous Message | David G. Johnston | 2023-01-12 00:52:46 | Re: pgsql: Add new GUC createrole_self_grant. |