Re: No Callbacks on FATAL

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: No Callbacks on FATAL
Дата
Msg-id 20230113175454.ct2o3jk63bw6wipj@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: No Callbacks on FATAL  (Aleksander Alekseev <aleksander@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: [EXTERNAL] Re: Support load balancing in libpq
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: PL/Python: Fix return in the middle of PG_TRY() block.