Re: backtrace_on_internal_error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: backtrace_on_internal_error
Date: 2023-12-08 15:05:09
Message-ID: 1439034.1702047909@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> Here is a patch to play with.

Didn't read the patch yet, but ...

> One possible question for discussion is whether the default for this
> should be off, on, or possibly something like on-in-assert-builds.
> (Personally, I'm happy to turn it on myself at run time, but everyone
> has different workflows.)

... there was already opinion upthread that this should be on by
default, which I agree with. You shouldn't be hitting cases like
this commonly (if so, they're bugs to fix or the errcode should be
rethought), and the failure might be pretty hard to reproduce.

I'm not really sold that we even need YA GUC, for that matter.
How about committing the behavior without a GUC, and then
back-filling one if we get pushback?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-12-08 16:29:03 Re: UBSan pointer overflow in xlogreader.c
Previous Message Peter Eisentraut 2023-12-08 14:48:43 Re: GUC names in messages