Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id 20210324152049.cjv2op3jsgauutwv@nol
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
List pgsql-hackers
On Wed, Mar 24, 2021 at 08:13:40AM -0400, Bruce Momjian wrote:
> On Wed, Mar 24, 2021 at 04:51:40PM +0800, Julien Rouhaud wrote:
> > > but if you do that it'd be better to avoid
> > > introducing a function with one name and renaming it in your next
> > > commit.
> > 
> > Oops, I apparently messed a fixup when working on it.  Bruce, should I take
> > care of that of do you want to?  I think you have some local modifications
> > already I'd rather not miss some changes.
> 
> I have no local modifications.  Please modify the patch I posted and
> repost your version, thanks.

Ok!  I used the last version of the patch you sent and addressed the following
comments from earlier messages in attached v20:

- copyright year to 2021
- s/has has been compute/has been compute/
- use the name CleanQuerytext in the first commit

I didn't change the position of queryid in pg_stat_get_activity(), as the
"real" order is actually define in system_views.sql when creating
pg_stat_activity view.  Adding the new fields at the end of
pg_stat_get_activity() helps to keep the C code simpler and less bug prone, so
I think it's best to continue this way.

I also used the previous commit message if that helps.

Attachment

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Robert Haas
Date:
Subject: Re: default result formats setting