Date: Tue, 25 Jun 2019 10:13:24 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: errbacktrace
Message-ID: <20190625141324.GA3260@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5f48cb47-bf1e-05b6-7aae-3bf2cd01586d@2ndquadrant.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Jun-25, Peter Eisentraut wrote:

> Here is a extended version of Álvaro's patch that adds an errbacktrace()
> function.

Great stuff, thanks for working on it.

> You can do two things with this:
> 
> - Manually attach it to an ereport() call site that you want to debug.
> 
> - Set a configuration parameter like backtrace_function = 'int8in' to
> debug ereport()/elog() calls in a specific function.

WFM.  I tried specifying int4in -- didn't work.  Turns out the errors
are inside another function which is what I have to put in
backtrace_function:

$ PGOPTIONS="-c backtrace_function=pg_strtoint32" psql

alvherre=# select int 'foobar';

2019-06-25 10:03:51.034 -04 [11711] ERROR:  invalid input syntax for type integer: "foobar" at character 12
2019-06-25 10:03:51.034 -04 [11711] BACKTRACE:  postgres: alvherre alvherre [local] SELECT(pg_strtoint32+0xef) [0x55862737bdaf]
	postgres: alvherre alvherre [local] SELECT(int4in+0xd) [0x558627336d7d]
	postgres: alvherre alvherre [local] SELECT(InputFunctionCall+0x7b) [0x55862740b10b]
	postgres: alvherre alvherre [local] SELECT(OidInputFunctionCall+0x48) [0x55862740b378]
	postgres: alvherre alvherre [local] SELECT(coerce_type+0x297) [0x5586270b2f67]
	postgres: alvherre alvherre [local] SELECT(coerce_to_target_type+0x9d) [0x5586270b37ad]
	postgres: alvherre alvherre [local] SELECT(+0x1ed3d8) [0x5586270b83d8]
	postgres: alvherre alvherre [local] SELECT(transformExpr+0x18) [0x5586270bbcc8]
	postgres: alvherre alvherre [local] SELECT(transformTargetEntry+0xb2) [0x5586270c81c2]
	postgres: alvherre alvherre [local] SELECT(transformTargetList+0x58) [0x5586270c9808]
	postgres: alvherre alvherre [local] SELECT(transformStmt+0x9d1) [0x55862708caf1]
	postgres: alvherre alvherre [local] SELECT(parse_analyze+0x57) [0x55862708f177]
	postgres: alvherre alvherre [local] SELECT(pg_analyze_and_rewrite+0x12) [0x5586272d2f02]
	postgres: alvherre alvherre [local] SELECT(+0x4085ca) [0x5586272d35ca]
	postgres: alvherre alvherre [local] SELECT(PostgresMain+0x1a37) [0x5586272d52b7]
	postgres: alvherre alvherre [local] SELECT(+0xbf635) [0x558626f8a635]
	postgres: alvherre alvherre [local] SELECT(PostmasterMain+0xf3e) [0x55862724e27e]
	postgres: alvherre alvherre [local] SELECT(main+0x723) [0x558626f8c603]
	/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f99d1931b97]
	postgres: alvherre alvherre [local] SELECT(_start+0x2a) [0x558626f8c6ca]

Didn't think too much about the libunwind format string (or even try to
compile it.)

Despite possible shortcomings in the produced backtraces, this is a
*much* more convenient interface than requesting users to attach gdb,
set breakpoint on errfinish, hey why does my SQL not run, "oh you forgot
'cont' in gdb", etc.

> There was also mention of settings that would automatically produce
> backtraces for PANICs etc.  Those could surely be added if there is
> enough interest.

Let's have the basics first, we can add niceties afterwards.  (IMO yes,
we should have backtraces in PANICs and assertion failures).

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services