Re: Printing backtrace of postgres processes
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: 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>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-14T15:16:00Z
Lists: pgsql-hackers
Attachments
- v11-0001-Print-backtrace-of-specified-postgres-process.patch (text/x-patch) patch v11-0001
- v11-0002-pg_print_backtrace-support-for-printing-backtrac.patch (text/x-patch) patch v11-0002
On Fri, Nov 12, 2021 at 5:15 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > On Thu, Nov 11, 2021 at 12:14 PM vignesh C <vignesh21@gmail.com> wrote: > > Thanks for the comments, the attached v10 patch has the fixes for the same. > > Thanks for the patches. Here are some comments: > > 1) In the docs, let's have the similar description of > pg_log_backend_memory_contexts for pg_print_backtrace, just for the > continuity in the users readability. I have kept some contents of the description similar. There is some additional information to explain more about the functionality. I felt that will help the user to understand more about the feature. > 2) I don't know how the <screen> part looks like in the Server > Signaling Functions table. I think here you can just say, it will emit > a warning and return false if not supported by the installation. And > you can give the <screen> part after the description where you are > showing a sample backtrace. > > + capture backtrace. If not available, the function will return false > + and a warning is issued, for example: > +<screen> > +WARNING: backtrace generation is not supported by this installation > + pg_print_backtrace > +-------------------- > + f > +</screen> > + </para></entry> > + </row> Modified > 3) Replace '!' with '.'. > + * Note: this is called within a signal handler! All we can do is set I have changed it similar to HandleLogMemoryContextInterrupt > 4) It is not only the next CFI but also the process specific interrupt > handlers (in your 0002 patch) right? > + * a flag that will cause the next CHECK_FOR_INTERRUPTS to invoke Modified > 5) I think you need to update CATALOG_VERSION_NO, mostly the committer > will take care of it but just in case. Modified > 6) Be consistent with casing "Verify" and "Might" > +# Verify that log output gets to the file > +# might need to retry if logging collector process is slow... Modified The attached v11 patch has the changes for the same. Regards, Vignesh
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