| 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 |
| Thread: | |
| 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.
Thanks!
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 |
| 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 |