Date: Thu, 14 May 2020 16:10:06 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Peter Geoghegan <pg@bowt.ie>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Bruce Momjian <bruce@momjian.us>,
	pgsql-hackers@postgresql.org
Subject: Re: PG 13 release notes, first draft
Message-ID: <20200514211006.GM18456@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAH2-WzmMq+53zOn+6VDhSHj2pa9mn0MLGx1KE3u38sP=0ObD9g@mail.gmail.com>
 <08a50ae9-89fe-a29b-c4e4-0fb5033c2f06@2ndquadrant.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Thu, May 14, 2020 at 11:01:51PM +0200, Peter Eisentraut wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of corruption.  If we were to include more "error" items,
> > we might also include these:
> > 
> > 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
> 
> This is actually a legitimate user-visible feature and should be listed
> somewhere.

On Thu, May 14, 2020 at 02:02:52PM -0700, Peter Geoghegan wrote:
> +1 -- it's very handy. Plus it has user-facing knobs.

That's already included:

| Allow function call backtraces of errors to be logged (Peter Eisentraut, Álvaro Herrera)
| Server variable backtrace_functions specifies which C functions should generate backtraces on error.

I 1) I failed to double check my list; and, 2) intended for that to be
interpretted as items which could be moved to a separate "error reporting"
section of the release notes.

-- 
Justin