Re: Bug in pg_stat_statements

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bug in pg_stat_statements
Date: 2025-10-24 14:17:22
Message-ID: CAA5RZ0sR-mhLdzuXrVVLcouAP4sf1qNnzBC5qq10TVbsTviROg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> This sort of short cut the verification for duplicated constants. Having said
> that it seems that another solution would be to check for duplicated constants
> in fill_in_constant_lengths just before skipping squashed constants and reset
> the length if needed.

Hi,

yes, I was not convinced my initial idea is good, and I ended up finding
another case that still breaks:

```
SELECT (ROW(ARRAY[1, 2], ARRAY[1, 2, 3])).*;
```

Here we have multiple squashable lists, and simply checking that the
location we are trying to record != the last location does not work. Also,
checking that the location we are trying to record is ahead of the last
location also does not work because the locations of squashable
lists in the predicate will be recorded first. So, we can't rely on the
location we want to record being higher than previous locations.
For example:

```
SELECT (ROW(ARRAY[1, 2], ARRAY[1, 2, 3])).* FROM t WHERE x
IN (1, 2, 3);
```

> Having said
> that it seems that another solution would be to check for duplicated constants
> in fill_in_constant_length

Yes, I started thinking along these lines as well, where we check for
duplicates
in fill_in_constant_length; or after jumbling, we de-duplicate locations if we
have a squashable list, which is what I have attached with updated test cases.

This means we do need to scan the locations one extra time during jumbling,
but I don't see that as a problem. Maybe there is another better way?

--
Sami Imseih
Amazon Web Services (AWS)

Attachment Content-Type Size
v2-0001-Fix-jumbling-of-squashed-lists-with-row-expansion.patch application/octet-stream 8.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-10-24 14:20:17 Re: Instability of phycodorus in pg_upgrade tests with JIT
Previous Message Nathan Bossart 2025-10-24 14:12:47 Re: display hot standby state in psql prompt