Re: Support a wildcard in backtrace_functions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support a wildcard in backtrace_functions
Дата
Msg-id ZiL758NcX8zY3c_M@paquier.xyz
обсуждение исходный текст
Ответ на Re: Support a wildcard in backtrace_functions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Support a wildcard in backtrace_functions  (Jelte Fennema-Nio <me@jeltef.nl>)
Список pgsql-hackers
On Fri, Apr 19, 2024 at 04:17:18PM -0400, Robert Haas wrote:
> On Fri, Apr 19, 2024 at 3:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I can't say that I care for "backtrace_on_internal_error".
>> Re-reading that thread, I see I argued for having *no* GUC and
>> just enabling that behavior all the time.  I lost that fight,
>> but it should have been clear that a GUC of this exact shape
>> is a design dead end --- and that's what we're seeing now.
>
> Yeah, I guess I have to agree with that.

Ah, I have missed this argument.

> So the question before us right now is whether there's a palatable
> alternative to completely ripping out a feature that both you and I
> seem to agree does something useful. I don't think we necessarily need
> to leap to the conclusion that a revert is radically less risky than
> some other alternative. Now, if there's not some obvious alternative
> upon which we can (mostly) all agree, then maybe that's where we end
> up. But I would like us to be looking to save the features we can.

Removing this GUC and making the backend react by default the same way
as when this GUC was enabled sounds like a sensible route here.  This
stuff is useful.
--
Michael

Вложения

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Direct SSL connection with ALPN and HBA rules
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Use XLOG_CONTROL_FILE macro everywhere?