Bug in pg_stat_statements

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Bug in pg_stat_statements
Date: 2025-10-23 16:21:33
Message-ID: 2b91e358-0d99-43f7-be44-d2d4dbce37b3@garret.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers.

In PG18 gthere is bug either in pg_stat_statements.c, either in
queryjumblefuncs.c.

Repro (you need Postgres build with asserts and pg_stat_statements
included in shared_preload_librarties:

create function f(a integer[], out x integer, out y integer) returns
record as $$            begin
       x = a[1];
       y = a[2];
   end;
$$ language plpgsql;

create table t(x integer);
select ((f(array[1,2]))).* from t;

The problems is caused by ((...)).* which cause to include the same
array literal twice in JumbleQuery.
But pg_stat_stataement assumes that any occurrence of constant is unique
and it cause assertion failure here:

        /* Copy next chunk (what precedes the next constant) */
        len_to_wrt = off - last_off;
        len_to_wrt -= last_tok_len;
        Assert(len_to_wrt >= 0);

So we should either exclude duplicates in RecordConstLocation
(queryjumblefuncs.c)
either in generate_normalized_query in pg_stat_statements.c

What is considered to be more correct?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2025-10-23 16:24:00 Re: CI: Add task that runs pgindent
Previous Message Srinath Reddy Sadipiralla 2025-10-23 16:08:23 Re: Making pg_rewind faster