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
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) |