BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data
Date
Msg-id 17552-213b534c56ab5d02@postgresql.org
Whole thread Raw
Responses Re: BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      17552
Logged by:          Maxim Boguk
Email address:      maxim.boguk@gmail.com
PostgreSQL version: 14.4
Operating system:   Linux
Description:

pg_stat_statements track internal FK trigger check queries during data load
via COPY
( pg_stat_statements.track=top (default) and
pg_stat_statements.track_utility=off (not default) )
Tested on latest 13 and 14 versions.

Test script (test.sql):

drop table if exists t1 CASCADE;
drop table if exists t2;

create table t1 (id integer primary key);
insert into t1 values (1);
vacuum ANALYZE t1;

create table t2 (id integer primary key, fk integer references t1(id));

create extension  IF NOT EXISTS  pg_stat_statements;
select  e.extname AS "Name", e.extversion AS "Version" FROM
pg_catalog.pg_extension e  where e.extname='pg_stat_statements';
show pg_stat_statements.track;
show pg_stat_statements.track_utility;

select pg_stat_statements_reset();

COPY public.t2 (id, fk) FROM stdin;
1    1
2    1
3    1
4    1
5    1
6    1
7    1
8    1
9    1
10    1
11    1
12    1
13    1
14    1
15    1
16    1
17    1
18    1
19    1
20    1
21    1
22    1
23    1
24    1
25    1
26    1
27    1
28    1
29    1
30    1
31    1
32    1
33    1
34    1
35    1
36    1
37    1
38    1
39    1
40    1
41    1
42    1
43    1
44    1
45    1
46    1
47    1
48    1
49    1
50    1
51    1
52    1
53    1
54    1
55    1
56    1
57    1
58    1
59    1
60    1
61    1
62    1
63    1
64    1
65    1
66    1
67    1
68    1
69    1
70    1
71    1
72    1
73    1
74    1
75    1
76    1
77    1
78    1
79    1
80    1
81    1
82    1
83    1
84    1
85    1
86    1
87    1
88    1
89    1
90    1
91    1
92    1
93    1
94    1
95    1
96    1
97    1
98    1
99    1
100    1
\.

select query, calls from public.pg_stat_statements where dbid=(select oid
from pg_database where datname=current_database()) order by calls desc limit
2;

run:
psql -e -f test.sql -d sometestdb

Final output rows:
select query, calls from public.pg_stat_statements where dbid=(select oid
from pg_database where datname=current_database()) order by calls desc limit
2;
                                            query
                | calls 
---------------------------------------------------------------------------------------------+-------
 SELECT $2 FROM ONLY "public"."t1" x WHERE "id" OPERATOR(pg_catalog.=) $1
FOR KEY SHARE OF x |   100
 select pg_stat_statements_reset()
                |     1
(2 rows)


Expected output:
                                            query
                | calls 
---------------------------------------------------------------------------------------------+-------
 select pg_stat_statements_reset()
                |     1
(1 rows)


PS: with pg_stat_statements.track_utility=on test work as expected and
provides expected
select query, calls from public.pg_stat_statements where dbid=(select oid
from pg_database where datname=current_database()) order by calls desc limit
2;
               query                | calls 
------------------------------------+-------
 COPY public.t2 (id, fk) FROM stdin |     1
 select pg_stat_statements_reset()  |     1



Regards,
Maxim


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty
Next
From: Tom Lane
Date:
Subject: Re: BUG #17483: postgres_fdw used with text to_tsvector and custom search configuration