| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> | 
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> | 
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: expose parallel leader in CSV and log_line_prefix | 
| Date: | 2020-07-10 16:39:09 | 
| Message-ID: | 20200710163909.sj2cbbovupzlesou@nol | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Fri, Jul 10, 2020 at 11:11:15AM -0500, Justin Pryzby wrote:
> On Fri, Jul 10, 2020 at 05:13:26PM +0200, Julien Rouhaud wrote:
> > There's a thinko in the padding handling.  It should be dones whether MyProc
> > and/or lockGroupLeader is NULL or not, and only if padding was asked, like it's
> > done for case 'd' for instance.
> > 
> > Also, the '%k' escape sounds a bit random.  Is there any reason why we don't
> > use any uppercase character for log_line_prefix?  %P could be a better
> > alternative, otherwise maybe %g, as GroupLeader/Gather?
> 
> Thanks for looking.  %P is a good idea - it's consistent with ps and pkill and
> probably other %commands.  I also amended the docs.
Thanks!
So for the leader == NULL case, the AppendStringInfoSpace is a no-op if no
padding was asked, so it's probably not worth adding extra code to make it any
more obvious.
It all looks good to me, I'm marking the patch a ready for committer!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-07-10 16:45:29 | Re: expose parallel leader in CSV and log_line_prefix | 
| Previous Message | Tom Lane | 2020-07-10 16:28:17 | Re: Stale external URL in doc? |