errbacktrace

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: errbacktrace
Date: 2019-06-25 11:08:21
Message-ID: 5f48cb47-bf1e-05b6-7aae-3bf2cd01586d@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

New thread continuing from
<https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2e73@2ndquadrant.com>.

Here is a extended version of Álvaro's patch that adds an errbacktrace()
function. 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.

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

For the implementation, I support both backtrace() provided by the OS as
well as using libunwind. The former seems to be supported by a number
of platforms, including glibc, macOS, and FreeBSD, so maybe we don't
need the libunwind suport. I haven't found any difference in quality in
the backtraces between the two approaches, but surely that is highly
dependent on the exact configuration.

I would welcome testing in all direction with this, to see how well it
works in different circumstances.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v2-0001-Add-errbacktrace-and-backtrace_function-GUC.patch text/plain 15.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-06-25 12:23:05 Re: fsync error handling in pg_receivewal, pg_recvlogical
Previous Message Amit Khandekar 2019-06-25 10:29:28 Re: Minimal logical decoding on standbys