Re: Printing backtrace of postgres processes
От | vignesh C |
---|---|
Тема | Re: Printing backtrace of postgres processes |
Дата | |
Msg-id | CALDaNm1_kj_NSeA5x--x4RsxP-0iZp-BjbkMb-gGyvjCNw5nxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Printing backtrace of postgres processes (vignesh C <vignesh21@gmail.com>) |
Список | pgsql-hackers |
On Thu, May 6, 2021 at 7:43 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > > Here's a cleaned-up copy of the doc text. > > Send a request to the backend with the specified process ID to log its backtrace. > The backtrace will be logged at message level <literal>LOG</literal>. > It will appear in the server log based on the log configuration set > (See <xref linkend="runtime-config-logging"/> for more information), > but will not be sent to the client regardless of > <xref linkend="guc-client-min-messages"/>. > A backtrace will identify where exactly the backend process is currently > executing. This may be useful to developers to diagnose stuck > processes and other problems. This feature is > not supported for the postmaster, logger, or statistics collector process. This > feature will be available if PostgreSQL was built > with the ability to capture backtracee. If not available, the function will > return false and show a WARNING. > Only superusers can request backends to log their backtrace. Thanks for rephrasing, I have modified to include checkpointer, walwriter and background writer process also. > > - * this and related functions are not inlined. > > + * this and related functions are not inlined. If edata pointer is valid > > + * backtrace information will set in edata. > > will *be* set Modified. Thanks for the comments, Attached v8 patch has the fixes for the same. Regards, Vignesh
Вложения
В списке pgsql-hackers по дате отправления: