The following bug has been logged on the website:
Bug reference: 17668
Logged by: Marcus Kempe
Email address: marcus.kempe@gmail.com
PostgreSQL version: 14.5
Operating system: Linux
Description:
Consider the following case:
postgres=# create function test(x bigint) returns void language sql as $$
select x ;$$;
CREATE FUNCTION
postgres=# select test(1);
test
------
(1 row)
postgres=# select calls,userid,dbid,queryid,query from
public.pg_stat_statements where query like 'select test%';
calls | userid | dbid | queryid | query
-------+--------+-------+----------------------+-----------------
1 | 10 | 13757 | -8729651821477628722 | select test($1)
(1 row)
postgres=# select test(12345678910); -- larger that INTMAX.
test
------
(1 row)
postgres=# select calls,userid,dbid,queryid,query from
public.pg_stat_statements where query like 'select test%';
calls | userid | dbid | queryid | query
-------+--------+-------+----------------------+-----------------
1 | 10 | 13757 | -8729651821477628722 | select test($1)
1 | 10 | 13757 | 1452143938866253601 | select test($1)
(2 rows)
So given the above 2 calls for the same function, there are 2 different
queryIds generated, seemingly based on the fact that in the first case the
parameter can be cast to integer, and in the second case it can not.
I would have expected both calls to be normalized and fingerprinted to one
and the same queryId.
This behavior was similar even before queryjumble.c was introduced in PG14.
