| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, 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 17:54:54 |
| Message-ID: | 20230113175454.ct2o3jk63bw6wipj@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-01-13 18:03:35 | Re: PL/Python: Fix return in the middle of PG_TRY() block. |
| Previous Message | Jelte Fennema | 2023-01-13 17:10:23 | Re: [EXTERNAL] Re: Support load balancing in libpq |