pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: Guillaume Lelarge <guillaume@lelarge.info>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Expose lock group leader pid in pg_stat_activity
Date: Tue, 28 Jan 2020 14:52:08 +0100
Message-ID: <20200128135208.6tnr72gamv2dr262@development> (raw)
In-Reply-To: <CAOBaU_YpsBA2puV8NtjV_Oit2jbt=wnNSA_2E41kGUi_BhA8rA@mail.gmail.com>
References: <CAOBaU_aFdiM=4w-UXtLfKgmcC7gwTQnJFWuxFA0CnPe9wgTnjg@mail.gmail.com>
	<2519941577437281@vla3-985002032993.qloud-c.yandex.net>
	<CAOBaU_Yaj8Zv-jXQu5VoowSf4kkTLGvFDg6ZZyfireBSVgooNQ@mail.gmail.com>
	<20200116072727.GI3117@paquier.xyz>
	<20200116074912.GA98418@paquier.xyz>
	<CAOBaU_ZPHkriFVYF=OrFyLsrXzcdzPizr0SPh+QdNBsHjT2GmQ@mail.gmail.com>
	<20200118025102.GB230692@paquier.xyz>
	<CAOBaU_Z6WcT8FJfcCMU_Bp+PTzUpTEY9BfBQE4gbGKpE5wpfwQ@mail.gmail.com>
	<20200128130910.anay3mlhaminob6w@development>
	<CAOBaU_YpsBA2puV8NtjV_Oit2jbt=wnNSA_2E41kGUi_BhA8rA@mail.gmail.com>

On Tue, Jan 28, 2020 at 02:26:34PM +0100, Julien Rouhaud wrote:
>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.

Yeah, sure. I mean explicit dependencies, e.g. a column referencing
values from another row, like leader_id does.

>Should I document the possible inconsistencies?

I think it's worth mentioning that as a comment in the code, say before
the pg_stat_get_activity function. IMO we don't need to document all
possible inconsistencies, a generic explanation is enough.

Not sure about the user docs. Does it currently say anything about this
topic - consistency with stat catalogs?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services





view thread (30+ messages)  latest in thread

Message-ID: <20200128135208.6tnr72gamv2dr262@development>
Permalink:  ../20200128135208.6tnr72gamv2dr262@development/
Also on:    postgresql.org/message-id/20200128135208.6tnr72gamv2dr262@development

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, rjuju123@gmail.com, michael@paquier.xyz, sk@zsrv.org, guillaume@lelarge.info, pgsql-hackers@lists.postgresql.org
  Subject: Re: Expose lock group leader pid in pg_stat_activity
  In-Reply-To: <20200128135208.6tnr72gamv2dr262@development>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox