Re: Expose lock group leader pid in pg_stat_activity

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Expose lock group leader pid in pg_stat_activity
Date: 2020-02-07 03:47:12
Message-ID: 20200207034712.GR23913@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-02-07 03:52:51 Re: SyncRepGetSyncStandbysPriority() vs. SIGHUP
Previous Message Kasahara Tatsuhito 2020-02-07 03:27:26 Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)