Re: Bug in pg_stat_statements - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Bug in pg_stat_statements
Date
Msg-id n3frj5fgiesu4o2uupviijusigqw42qvxymupq3czdiljfj2ik@ehvug46al5qq
Whole thread Raw
In response to Re: Bug in pg_stat_statements  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Bug in pg_stat_statements
List pgsql-hackers
> On Thu, Oct 23, 2025 at 07:49:55PM -0500, Sami Imseih wrote:
> I believe the correct answer is to fix this in queryjumblefuncs.c
> and more specifically inside _jumbleElements. We should not
> record the same location twice. We can do this by tracking the
> start location of  the last recorded constant location, and we
> can skip recording it if we see it again. See the attached
> which also includes test cases.

I think there is another option. Before squashing implementation, duplicated
constants were dealt with in fill_in_constant_lengths -- after processing their
length was -1 and such constants were skipped further down the line. After
0f65f3eec, if such a constant is supposed to be squashed we now ignore it, but
set the length anyway in RecordConstLocation:

    if (locs[i].squashed)
        continue;           /* squashable list, ignore */

    if (loc <= last_loc)
        continue;           /* Duplicate constant, ignore */

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.



pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: ci: Improve OpenBSD core dump backtrace handling
Next
From: Bryan Green
Date:
Subject: Re: Avoid handle leak (src/bin/pg_ctl/pg_ctl.c)