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
atthe 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_utilityis 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