Re: Support a wildcard in backtrace_functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema-Nio <me(at)jeltef(dot)nl>, 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-26 15:57:48
Message-ID: CA+TgmobEd4E5b6rhfmUPP+-uSB2ttqPiDNfexOZfeW_yWEB1qA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 23, 2024 at 1:05 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> At this stage, my opinion would tend in favor of a revert of the GUC.
> The second class of cases is useful to stress many unexpected cases,
> and I don't expect this number to go down over time, but increase with
> more advanced tests added into core (I/O failures with partial writes
> for availability, etc).

All right. I think there is a consensus in favor of reverting
a740b213d4b4d3360ad0cac696e47e5ec0eb8864. Maybe not an absolutely
iron-clad consensus, but there are a couple of votes explicitly in
favor of that course of action and the other votes seem to mostly be
of the form "well, reverting is ONE option."

Peter?

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-26 16:15:27 Re: Why don't we support external input/output functions for the composite types
Previous Message Tom Lane 2024-04-26 15:55:57 Re: Why don't we support external input/output functions for the composite types