| From: | Sergei Kornilov <sk(at)zsrv(dot)org> | 
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> | 
| Cc: | maxim(dot)boguk(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data | 
| Date: | 2023-03-22 12:21:07 | 
| Message-ID: | 430591679487667@lma6oifqwmuo4pt7.myt.yp-c.yandex.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
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
| Attachment | Content-Type | Size | 
|---|---|---|
| v1-0001-testcase-wrong-toplevel.patch | text/x-diff | 3.4 KB | 
| v1-0002-increment-nested-level-utility.patch | text/x-diff | 1.2 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2023-03-22 12:47:05 | BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values | 
| Previous Message | Alexander Lakhin | 2023-03-22 07:00:00 | Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls |