Re: errbacktrace - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: errbacktrace
Date
Msg-id 20190625141324.GA3260@alvherre.pgsql
Whole thread Raw
In response to errbacktrace  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Ildar Musin
Date:
Subject: Duplicated LSN in ReorderBuffer