| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Ed Behn <ed(at)behn(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: No Callbacks on FATAL |
| Date: | 2023-01-12 01:17:27 |
| Message-ID: | 782965.1673486247@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-01-11 18:10:33 -0500, Tom Lane wrote:
>> 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.
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.
As you say, we really need more details to see what's happening
here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2023-01-12 01:32:18 | Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans |
| Previous Message | Tom Lane | 2023-01-12 01:06:22 | Re: on placeholder entries in view rule action query's range table |