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 →
-
Fix some issues with tracking nesting level in pg_stat_statements.
- 76db9cb6368e 17.0 landed
Attachments
- v1-0001-testcase-wrong-toplevel.patch (text/x-diff) patch v1-0001
- v1-0002-increment-nested-level-utility.patch (text/x-diff) patch v1-0002
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