Re: No Callbacks on FATAL

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: No Callbacks on FATAL
Дата
Msg-id CAJ7c6TMYwE-oVLh3DZWroj-XdSKOooGx=GKuW4MkR3iO6pL7Vg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: No Callbacks on FATAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: No Callbacks on FATAL  (Andres Freund <andres@anarazel.de>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: PG11 to PG14 Migration Slowness
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: BF animal malleefowl reported an failure in 001_password.pl