From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Julien Rouhaud <julien.rouhaud@free.fr>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Evgeny Efimkin <efimkin@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date: Sat, 1 Feb 2020 12:30:45 +0100
Message-ID: <20200201113045.x4qj36uvt34ymwiy@development> (raw)
In-Reply-To: <CAOBaU_Z-aXmCStY1DumXo_fbc3eAMwUYw2QjV8NpAS6DVc7J6A@mail.gmail.com>
References: <1565026229657-0.post@n3.nabble.com>
<156516860141.18864.14200401842491641374.pgcf@coridan.postgresql.org>
<20190911044523.GF1953@paquier.xyz>
<CAOBaU_aQKkB3HehOp820ssJXBQbGiAQjxvB_8ynNG2g4MbUUjA@mail.gmail.com>
<20191111083730.GD1418@paquier.xyz>
<20191113031523.GD14545@momjian.us>
<CAOBaU_aBN43AYi+7WyOzyOkFQV9mFeAzFS=j-Q1u1+UPt_P9Lw@mail.gmail.com>
<20191129061949.GJ2505@paquier.xyz>
<20191129062058.GK2505@paquier.xyz>
<CAOBaU_Z-aXmCStY1DumXo_fbc3eAMwUYw2QjV8NpAS6DVc7J6A@mail.gmail.com>
On Fri, Nov 29, 2019 at 09:39:09AM +0100, Julien Rouhaud wrote:
>On Fri, Nov 29, 2019 at 7:21 AM Michael Paquier <michael@paquier.xyz> wrote:
>>
>> On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote:
>> > On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote:
>> >> I'd really like to have the queryid function available through SQL,
>> >> but I think that this specific case wouldn't work very well for
>> >> pg_stat_statements' approach as it's working with oid. The query
>> >> string in pg_stat_activity is the user provided one rather than a
>> >> fully-qualified version, so in order to get that query's queryid, you
>> >> need to know the exact search_path in use in that backend, and that's
>> >> not something available.
>> >
>> > Yeah.. So, we have a patch marked as ready for committer here, and it
>> > seems to me that we have a couple of issues to discuss more about
>> > first particularly this query ID of 0. Again, do others have more
>> > any input to offer?
>
>I just realized that with current infrastructure it's not possible to
>display a utility queryid. We need to recognize utility to not
>process the counters twice (once in processUtility, once in the
>underlying executor), so we don't provide a queryid for utility
>statements in parse analysis. Current magic value 0 has the side
>effect of showing an invalid queryid for all utilty statements, and
>using a magic value different from 0 will just always display that
>magic value. We could instead add another field in the Query and
>PlannedStmt structs, say "int queryid_flags", that extensions could
>use for their needs?
>
>> And while on it, the latest patch does not apply, so a rebase is
>> needed here.
>
>Yep, I noticed that this morning. I already rebased the patch
>locally, I'll send a new version with new modifications when we reach
>an agreement on the utility issue.
>
Well, this patch was in WoA since November, but now that I look at it
that might have been wrong - we're clearly waiting for agreement on how
to handle queryid for utility commands. I suspect the WoA status might
have been driving people away from this thread :-(
I've switched the patch to "needs review" and moved it to the next CF.
What I think needs to happen is we get a patch implementing one of the
proposed solutions, and discuss that.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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, julien.rouhaud@free.fr, michael@paquier.xyz, bruce@momjian.us, efimkin@yandex-team.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
In-Reply-To: <20200201113045.x4qj36uvt34ymwiy@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