Horton

Re: Printing backtrace of postgres processes

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Craig Ringer <craig.ringer@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2021-11-15T19:42:51Z
Lists: pgsql-hackers 
On Mon, Nov 15, 2021 at 09:12:49PM +0530, vignesh C wrote:
> The idea here is to implement & expose pg_print_backtrace function, internally

This patch is closely related to this one
https://commitfest.postgresql.org/35/3142/
| Logging plan of the currently running query

I suggest to review that patch and make sure there's nothing you could borrow.

My only comment for now is that maybe the function name should be
pg_log_backtrace() rather than pg_print_backtrace(), since it doesn't actually
"print" the backtrace, but rather request the other backend to log its
backtrace.

Did you see that the windows build failed ?
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.153557

I think you'll need to create an "alternate" output like
src/test/regress/expected/misc_functions_1.out

It's possible that's best done by creating a totally new .sql and .out files
added to src/test/regress/parallel_schedule - because otherwise, you'd have to
duplicate the existing 300 lines of misc_fuctions.out.

-- 
Justin

Commits

  1. Perform apply of large transactions by parallel workers.

  2. Enhance pg_log_backend_memory_contexts() for auxiliary processes.

  3. Allow GRANT on pg_log_backend_memory_contexts().

  4. Move Perl test modules to a better namespace

  5. Unify PostgresNode's new() and get_new_node() methods

  6. Add backtrace support for error reporting