Re: Expose lock group leader pid in pg_stat_activity

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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>
Subject: Re: Expose lock group leader pid in pg_stat_activity
Date: 2020-02-06 08:23:33
Message-ID: 20200206082333.GA95343@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 06, 2020 at 09:24:16AM +0900, Michael Paquier wrote:
> On Wed, Feb 05, 2020 at 07:57:20AM +0100, Julien Rouhaud wrote:
> > This looks good, thanks a lot!
> Thanks for double-checking. And done.


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?

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.

Attachment Content-Type Size
prockill-typo.diff text/plain 596 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2020-02-06 08:30:32 Re: [HACKERS] WIP: Aggregation push-down
Previous Message Masahiko Sawada 2020-02-06 08:18:59 Re: Identifying user-created objects