Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Printing backtrace of postgres processes
Date
Msg-id CALj2ACUFD-CW4n+Piu8pq9TYs1keAz_ga5C-6ZbjWrUGZ1GCMQ@mail.gmail.com
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Responses Re: Printing backtrace of postgres processes
Re: Printing backtrace of postgres processes
List pgsql-hackers
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.

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>

3) Replace '!' with '.'.
+ * Note: this is called within a signal handler!  All we can do is set

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

5) I think you need to update CATALOG_VERSION_NO, mostly the committer
will take care of it but just in case.

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...


Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Allow users to choose what happens when recovery target is not reached
Next
From: Bharath Rupireddy
Date:
Subject: Re: Printing backtrace of postgres processes