Re: Printing backtrace of postgres processes
От | vignesh C |
---|---|
Тема | Re: Printing backtrace of postgres processes |
Дата | |
Msg-id | CALDaNm3BYGOG3-PQvYbWkB=G3h1KYJ8CO8UYbzfECH4DYGMGqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Printing backtrace of postgres processes (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: