Re: expose parallel leader in CSV and log_line_prefix
От | Julien Rouhaud |
---|---|
Тема | Re: expose parallel leader in CSV and log_line_prefix |
Дата | |
Msg-id | 20200710163909.sj2cbbovupzlesou@nol обсуждение исходный текст |
Ответ на | Re: expose parallel leader in CSV and log_line_prefix (Justin Pryzby <pryzby@telsasoft.com>) |
Список | 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!
В списке pgsql-hackers по дате отправления: