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

From vignesh C
Subject Re: Printing backtrace of postgres processes
Date
Msg-id CALDaNm23QRvW-Y6Yf0rHDMUWpsROD2j4DjwasvowzCJqTbpqhw@mail.gmail.com
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
On Mon, Jan 24, 2022 at 10:06 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2022/01/24 16:35, torikoshia wrote:
> > On 2022-01-14 19:48, Bharath Rupireddy wrote:
> >> On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
> >> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >>>
> >>> On Fri, Nov 19, 2021 at 4:07 PM vignesh C <vignesh21@gmail.com> wrote:
> >>> > The Attached v15 patch has the fixes for the same.
> >>>
> >>> Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as RfC.
> >>
> >> The patch was not applying because of the recent commit [1]. I took
> >> this opportunity and tried a bunch of things without modifying the
> >> core logic of the pg_log_backtrace feature that Vignesh has worked on.
>
> I have one question about this feature. When the PID of auxiliary process like archiver is specified, probably the
functionalways reports the same result, doesn't it? Because, for example, the archiver always logs its backtrace in
HandlePgArchInterrupts().

It can be either from HandlePgArchInterrupts in pgarch_MainLoop or
from HandlePgArchInterrupts in pgarch_ArchiverCopyLoop, since the
archiver functionality is mainly in these functions.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_dump new feature: exporting functions only. Bad or good idea ?
Next
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication