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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiro Ikeda
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [PATCH] Add support for choosing huge page size