Re: Correctly propagate queryId for utility stmt in function

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Correctly propagate queryId for utility stmt in function
Date: 2024-07-19 00:13:11
Message-ID: Zpmvly3YGDH6OWGz@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 18, 2024 at 01:37:40PM +0200, Anthonin Bonnefoy wrote:
> For utility statements defined within a function, the queryTree is
> copied to a plannedStmt as utility commands don't require planning.
> However, the queryId is not propagated to the plannedStmt. This leads
> to plugins relying on queryId like pg_stat_statements to not be able
> to track utility statements within function calls.

You are right, good catch. This leads to only partial information
being reported depending on the setting of pg_stat_statements.track.
It is a point of detail, but I'd rather expand a bit more the tests on
top of what you are proposing:
- Upper and down-casing for non-top utility commands, to check that
they are counted consistently.
- Check with pg_stat_statements.track = 'top'
- Not cross-checking pg_stat_statements.track_utility = false is OK.

While this qualifies as something that could go down to all the stable
branches, it is much easier to think about utility statements in 16~
now that we compile the query IDs depending on their parsed tree, so
will apply down to that.

pg_stat_statements tests have also been refactored in 16~, but that's
a nit here..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 김명준 2024-07-19 00:30:52 Re: [ pg_ctl ] Review Request for Adding Pre-check User Script Feature
Previous Message jian he 2024-07-19 00:11:00 Re: Adding OLD/NEW support to RETURNING