Re: Expose lock group leader pid in pg_stat_activity - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Expose lock group leader pid in pg_stat_activity
Date
Msg-id CAOBaU_YpsBA2puV8NtjV_Oit2jbt=wnNSA_2E41kGUi_BhA8rA@mail.gmail.com
Whole thread Raw
In response to Re: Expose lock group leader pid in pg_stat_activity  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Expose lock group leader pid in pg_stat_activity  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Tue, Jan 28, 2020 at 2:09 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> I agree a separate "leader_id" column is easier to work with, as it does
> not require unnesting and so on.
>
> As for the consistency, I agree we probably can't make this perfect, as
> we're fetching and processing the PGPROC records one by one. Fixing that
> would require acquiring a much stronger lock on PGPROC, and perhaps some
> other locks. That's pre-existing behavior, of course, it's just not very
> obvious as we don't have any dependencies between the rows, I think.
> Adding the leader_id will change, that, of course. But I think it's
> still mostly OK, even with the possible inconsistency.

There were already some dependencies between the rows since parallel
queries were added, as you could see eg. a parallel worker while no
query is currently active.  This patch will make those corner cases
more obvious.  Should I document the possible inconsistencies?



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Expose lock group leader pid in pg_stat_activity
Next
From: Justin Pryzby
Date:
Subject: tableam options for pg_dump/ALTER/LIKE