Re: errbacktrace

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: errbacktrace
Date: 2019-06-25 14:13:24
Message-ID: 20190625141324.GA3260@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ildar Musin 2019-06-25 14:45:57 Duplicated LSN in ReorderBuffer
Previous Message Robert Haas 2019-06-25 13:44:20 Re: Minimal logical decoding on standbys