Horton

Thread

Commits

  1. Propagate query IDs of utility statements in functions

  1. Correctly propagate queryId for utility stmt in function

    Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> — 2024-07-18T11:37:40Z

    Hi,

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.

This patch fixes the issue by correctly propagating queryId from the
cached queryTree to the plannedStmt.

Regards,
Anthonin

  2. Re: Correctly propagate queryId for utility stmt in function

    Michael Paquier <michael@paquier.xyz> — 2024-07-19T00:13:11Z

    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