Re: PANIC serves too many masters

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PANIC serves too many masters
Дата
Msg-id 1375174.1700518354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PANIC serves too many masters  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: PANIC serves too many masters  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Sat, 2023-11-18 at 14:29 -0800, Andres Freund wrote:
>> I don't quite know what we should do. But the current situation
>> decidedly
>> doesn't seem great.

> Agreed.

+1

> Better classification is nice, but it also requires more
> discipline and it might not always be obvious which category something
> fits in. What about an error loop resulting in:
>   ereport(PANIC, (errmsg_internal("ERRORDATA_STACK_SIZE exceeded")));
> We'd want a core file, but I don't think we want to restart in that
> case, right?

Why not restart?  There's no strong reason to assume this will
repeat.

It might be worth having some independent logic in the postmaster
that causes it to give up after too many crashes in a row.  But with
many/most of these call sites, by definition we're not too sure what
is wrong.

> Also, can we do a change like this incrementally by updating a few
> PANIC sites at a time? Is it fine to leave plain PANICs in place for
> the foreseeable future, or do you want all of them to eventually move?

I'd be inclined to keep PANIC with its current meaning, and
incrementally change call sites where we decide that's not the
best behavior.  I think those will be a minority, maybe a small
minority.  (PANIC_EXIT had darn well better be a small minority.)

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Annoying build warnings from latest Apple toolchain
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }