Message-ID: <8dd1ef3e-378c-83dc-229b-e3d3e251ac11@enterprisedb.com>
Date: Sun, 16 Jul 2023 17:19:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: BUG #17552: pg_stat_statements tracks internal FK check queries
 when COPY used to load data
Content-Language: en-US
To: Sergei Kornilov <sk@zsrv.org>, Julien Rouhaud <rjuju123@gmail.com>
Cc: maxim.boguk@gmail.com, pgsql-bugs@lists.postgresql.org
References: <17552-213b534c56ab5d02@postgresql.org>
 <20220718101955.5erjttxbbjupm2xr@jrouhaud>
 <430591679487667@lma6oifqwmuo4pt7.myt.yp-c.yandex.net>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <430591679487667@lma6oifqwmuo4pt7.myt.yp-c.yandex.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/8dd1ef3e-378c-83dc-229b-e3d3e251ac11%40enterprisedb.com>
Precedence: bulk

On 3/22/23 13:21, Sergei Kornilov wrote:
> Hello
> 
> I have a similar problem with exactly the same reason. Queries are counted as top level, although they are not called at the top level. Another small example:
> 
> set pg_stat_statements.track_utility to off;
> set pg_stat_statements.track to 'top';
> do $$ declare i int; begin select 1 as n into i; end $$ language plpgsql;
> select toplevel, query from pg_stat_statements order by query;
>  toplevel |               query               
> ----------+-----------------------------------
>  t        | select $1 as n
>  t        | select pg_stat_statements_reset()
> (2 rows)
> 
> But "select $1 as n" was not a top-level query.
> 
> In the first patch, a testcase showing the behavior now. The second patch adds a nesting level increment if track_utility is disabled. I need to duplicate the PGSS_HANDLED_UTILITY check here because it's documented above:
> 
>> If it's an EXECUTE statement, we don't track it and don't increment the nesting level.
> 

I took a look, and the patch seems correct to me. It'll need better
comments explaining the change, but I'll take care of that. Barring
objections, I'll get this committed and backpatched.

FWIW it's probably a good idea to post patches on pgsql-hackers - not
everyone watches pgsql-bugs and/or CF app. Furthermore, when a patch is
switched to "RFC" it's customary to mention that in the thread, along
with a review. Otherwise these silent changes are quite puzzling.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company