Re: Query Jumbling for CALL and SET utility statements - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: Query Jumbling for CALL and SET utility statements
Date
Msg-id 4086e6f0-d954-4ceb-cfa0-88b622b1d1bc@gmail.com
Whole thread Raw
In response to Re: Query Jumbling for CALL and SET utility statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Query Jumbling for CALL and SET utility statements
List pgsql-hackers
Hi,

On 9/21/22 6:07 PM, Fujii Masao wrote:
> 
> 
> On 2022/09/19 15:29, Drouvot, Bertrand wrote:
>> Please find attached v6 taking care of the remarks mentioned above.
> 
> Thanks for updating the patch!
> 
> +SET pg_stat_statements.track_utility = TRUE;
> +
> +-- PL/pgSQL procedure and pg_stat_statements.track = all
> +-- we drop and recreate the procedures to avoid any caching funnies
> +SET pg_stat_statements.track_utility = FALSE;
> 
> Could you tell me why track_utility is enabled just before it's disabled?

Thanks for looking at the new version!

No real reason, I removed those useless SET in the new V7 attached.

> 
> Could you tell me what actually happens if we don't drop and
> recreate the procedures? I'd like to know what "any caching funnies" are.

Without the drop/recreate the procedure body does not appear normalized 
(while the CALL itself is) when switching from track = top to track = all.

I copy-pasted this comment from the already existing "function" section 
in the pg_stat_statements.sql file. This comment has been introduced for 
the function section in commit 83f2061dd0. Note that the behavior would 
be the same for the function case (function body does not appear 
normalized without the drop/recreate).

> 
> +SELECT pg_stat_statements_reset();
> +CALL MINUS_TWO(3);
> +CALL MINUS_TWO(7);
> +CALL SUM_TWO(3, 8);
> +CALL SUM_TWO(7, 5);
> +
> +SELECT query, calls, rows FROM pg_stat_statements ORDER BY query 
> COLLATE "C";
> 
> This test set for the procedures is executed with the following
> four conditions, respectively. Do we really need all of these tests?
> 
> track = top, track_utility = true
> track = top, track_utility = false
> track = all, track_utility = true
> track = all, track_utility = false

Oh right, the track_utility = false cases have been added when we 
decided up-thread to force track CALL.

But now that's probably not needed to test with track_utility = true. So 
I'm just keeping track_utility = off with track = top or all in the new 
V7 attached (like this is the case for the "function" section).

> 
> +begin;
> +prepare transaction 'tx1';
> +insert into test_tx values (1);
> +commit prepared 'tx1';
> 
> The test set of 2PC commands is also executed with track_utility = on
> and off, respectively. But why do we need to run that test when
> track_utility = off?

That's useless, thanks for pointing out. Removed in V7 attached.

> 
> -    if (query->utilityStmt)
> +    if (query->utilityStmt && !jstate)
>       {
>           if (pgss_track_utility && 
> !PGSS_HANDLED_UTILITY(query->utilityStmt))
> 
> "pgss_track_utility" should be
> "pgss_track_utility || FORCE_TRACK_UTILITY(parsetree)" theoretically?

Good catch! That's not needed (in practice) with the current code but 
that is "theoretically" needed indeed, let's add it in V7 attached 
(that's safer should the code change later on).


Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Bilal Yavuz
Date:
Subject: kerberos/001_auth test fails on arm CPU darwin