Re: Expose lock group leader pid in pg_stat_activity

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Expose lock group leader pid in pg_stat_activity
Дата
Msg-id 20200207034712.GR23913@paquier.xyz
обсуждение исходный текст
Ответ на Re: Expose lock group leader pid in pg_stat_activity  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Thu, Feb 06, 2020 at 09:23:33AM +0100, Julien Rouhaud wrote:
> While on the topic, is there any reason why the backend stays a group leader
> for the rest of its lifetime, and should we change that?

Nothing happens without a reason.  a1c1af2 is the original commit, and
the thread is here:
https://www.postgresql.org/message-id/CA+TgmoapgKdy_Z0W9mHqZcGSo2t_t-4_V36DXaKim+X_fYp0oQ@mail.gmail.com

By looking at the surroundings, there are a couple of assumptions
behind the timing of the shutdown for the workers and the leader.
I have not studied much the details on that, but my guess is that it
makes the handling of the leader shutting down before its workers
easier.  Robert or Amit likely know all the details here.

> Also, while reading ProcKill, I noticed a typo in a comment:
>
>     /*
>      * Detach from any lock group of which we are a member.  If the leader
> -    * exist before all other group members, it's PGPROC will remain allocated
> +    * exist before all other group members, its PGPROC will remain allocated
>      * until the last group process exits; that process must return the
>      * leader's PGPROC to the appropriate list.
>      */

Thanks, fixed.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kasahara Tatsuhito
Дата:
Сообщение: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: SyncRepGetSyncStandbysPriority() vs. SIGHUP