| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, 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-21 07:26:38 |
| Message-ID: | ff916003-8dc2-426f-af4c-d7cdc9437968@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 19.04.24 21:24, Tom Lane wrote:
>> 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.
Note that a standard test run produces a number of internal errors. I
haven't checked how likely these are in production, but one might want
to consider that before starting to dump backtraces in routine situations.
For example,
$ PG_TEST_INITDB_EXTRA_OPTS='-c backtrace_on_internal_error=on' meson
test -C build
$ grep -r 'BACKTRACE:' build/testrun | wc -l
85
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-04-21 11:52:36 | Re: Support a wildcard in backtrace_functions |
| Previous Message | Justin Pryzby | 2024-04-21 01:25:48 | Re: pgsql: Fix restore of not-null constraints with inheritance |