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: