Re: Set query_id for query contained in utility statement

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-18T06:21:03Z
Lists: pgsql-hackers
On Thu, Oct 17, 2024 at 09:21:11AM +0200, Anthonin Bonnefoy wrote:
> I'm not sure about this approach. It moves the responsibility of
> tracking the location and length from the nested statement to the top
> level statement.
> - The location you added in ExplainStmt and CopyStmt has a different
> meaning from all others and tracks the nested location and not the
> location of the statement itself. This creates some inconsistencies.
> - The work will need to be done for all statements with nested
> queries: Prepare, Create table as, Declare Cursor, Materialised View.
> Whereas by tracking the location of PreparableStatements, there's no
> need for additional logic. For example, v8 0002 fixes the existing
> behaviour for Prepare statements thanks to SelectStmt's modifications.

Hmm.  And isn't tracking this information at only the top-level going
to be a problem when dealing with multiple levels of nesting, when for
example these involve pl/sql or pl/pgSQL functions?  How would this
work if we're dealing with multiple levels of Nodes?
--
Michael

Commits

  1. Set query ID for inner queries of CREATE TABLE AS and DECLARE

  2. Track more precisely query locations for nested statements

  3. pg_stat_statements: Add tests for nested queries with level tracking

  4. Fix race condition in COMMIT PREPARED causing orphaned 2PC files