Re: Printing backtrace of postgres processes
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, vignesh C <vignesh21@gmail.com>, torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-08T03:25:18Z
Lists: pgsql-hackers
On Thu, Feb 08, 2024 at 12:30:00AM +0530, Bharath Rupireddy wrote: > I've missed adding LoadBacktraceFunctions() in InitAuxiliaryProcess > for 0002 patch. Please find the attached v29 patch set. Sorry for the > noise. I've been torturing the patch with \watch and loops calling the function while doing a sequential scan of pg_stat_activity, and that was stable while doing a pgbench and an installcheck-world in parallel, with some infinite loops and some spinlocks I should not have taken. + if (backtrace_functions_loaded) + return; I was really wondering about this point, particularly regarding the fact that this would load libgcc for all the backends when they start, unconditionally. One thing could be to hide that behind a postmaster GUC disabled by default, but then we'd come back to using gdb on a live server, which is no fun on a customer environment because of the extra dependencies, which may not, or just cannot, be installed. So yeah, I think that I'm OK about that. + * procsignal.h + * Backtrace-related routines This one is incorrect. In HandleLogBacktraceInterrupt(), we don't use backtrace_symbols() and rely on backtrace_symbols_fd() to avoid doing malloc() in the signal handler as mentioned in [1] back in 2022. Perhaps the part about the fact that we don't use backtrace_symbols() should be mentioned explicitely in a comment rather than silently implied? That's a very important point. Echoing with upthread, and we've been more lax with superuser checks and assignment of custom roles in recent years, I agree with the approach of the patch to make that superuser by default. Then users can force their own policy as they want with an EXECUTE ACL on the SQL function. As a whole, I'm pretty excited about being able to rely on that without the need to use gdb to get a live trace. Does anybody have objections and/or comments, particularly about the superuser and the load part at backend startup? This thread has been going on for so long that it would be good to let 1 week for folks to react before doing anything. See v29 for references. [1]: https://www.postgresql.org/message-id/CALj2ACUNZVB0cQovvKBd53-upsMur8j-5_K=-fg86uAa+WYEWg@mail.gmail.com -- Michael
Commits
-
Perform apply of large transactions by parallel workers.
- 216a784829c2 16.0 cited
-
Enhance pg_log_backend_memory_contexts() for auxiliary processes.
- 790fbda90209 15.0 cited
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited
-
Move Perl test modules to a better namespace
- b3b4d8e68ae8 15.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited
-
Add backtrace support for error reporting
- 71a8a4f6e365 13.0 cited