Re: expose parallel leader in CSV and log_line_prefix - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: expose parallel leader in CSV and log_line_prefix
Date
Msg-id 20200315114933.udjdx5wcgwkjnw45@nol
Whole thread Raw
In response to expose parallel leader in CSV and log_line_prefix  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: expose parallel leader in CSV and log_line_prefix
List pgsql-hackers
On Sun, Mar 15, 2020 at 06:18:31AM -0500, Justin Pryzby wrote:
> See also:
> https://commitfest.postgresql.org/27/2390/
> https://www.postgresql.org/message-id/flat/CAOBaU_Yy5bt0vTPZ2_LUM6cUcGeqmYNoJ8-Rgto+c2+w3defYA@mail.gmail.com
> b025f32e0b Add leader_pid to pg_stat_activity


FTR this is a followup of https://www.postgresql.org/message-id/20200315095728.GA26184%40telsasoft.com

+1 for the feature.  Regarding the patch:


+           case 'k':
+               if (MyBackendType != B_BG_WORKER)
+                   ; /* Do nothing */


Isn't the test inverted?  Also a bgworker could run parallel queries through
SPI I think, should we really ignore bgworkers?

+               else if (!MyProc->lockGroupLeader)
+                   ; /* Do nothing */


There should be a test that MyProc isn't NULL.

+               else if (padding != 0)
+                   appendStringInfo(buf, "%*d", padding, MyProc->lockGroupLeader->pid);
+               else
+                   appendStringInfo(buf, "%d", MyProc->lockGroupLeader->pid);
+               break;

I think that if padding was asked we should append spaces rather than doing
nothing.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: expose parallel leader in CSV and log_line_prefix
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager