Re: expose parallel leader in CSV and log_line_prefix
От | Michael Paquier |
---|---|
Тема | Re: expose parallel leader in CSV and log_line_prefix |
Дата | |
Msg-id | 20200717024107.GC29811@paquier.xyz обсуждение исходный текст |
Ответ на | Re: expose parallel leader in CSV and log_line_prefix (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: expose parallel leader in CSV and log_line_prefix
|
Список | pgsql-hackers |
On Fri, Jul 10, 2020 at 01:16:40PM -0400, Alvaro Herrera wrote: > On 2020-Jul-10, Justin Pryzby wrote: >> That's what's done. >> >> + <entry>Process ID of the parallel group leader if this process was >> + at some point involved in parallel query, otherwise null. For a >> + parallel group leader itself, this field is set to its own process >> + ID.</entry> > > Oh, okay by me then. Please note that this choice comes from BecomeLockGroupLeader(), where a leader registers itself in lockGroupLeader, and remains set as such as long as the process is alive so we would always get a value for a process once it got involved in parallel query. This patch is just doing what we do in pg_stat_get_activity(), with the padding handling. It is true that this may cause log_line_prefix to be overly verbose in the case where you keep a lot of sessions alive for long time when they got all involved at least once in parallel query as most of them would just refer to their own PID, but I think that it is better to be consistent with what we do already with pg_stat_activity, as that's the data present in the PGPROC entries. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: