Re: BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data

Sergei Kornilov <sk@zsrv.org>

From: Sergei Kornilov <sk@zsrv.org>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: maxim.boguk@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-03-22T12:21:07Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix some issues with tracking nesting level in pg_stat_statements.

Attachments

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.

regards, Sergei