Re: Support a wildcard in backtrace_functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jelte Fennema-Nio <me(at)jeltef(dot)nl>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support a wildcard in backtrace_functions
Date: 2024-04-19 20:17:18
Message-ID: CA+TgmobYGQju3wPhr93siKnpn8w9GPTqw=tj0enO7R85R0Me-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 19, 2024 at 3:24 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

> > But on the other hand, in my personal experience,
> > backtrace_on_internal_error would be the right thing in a really large
> > number of cases.
>
> That's why I thought we could get away with doing it automatically.
> Sure, more control would be better. But if we just hard-wire it for
> the moment then we aren't locking in what the eventual design for
> that control will be.

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.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-19 20:18:13 Re: fix tablespace handling in pg_combinebackup
Previous Message Tom Lane 2024-04-19 20:14:56 Re: postgres_fdw fails because GMT != UTC