Subject: Re: [[BUG] pg_stat_statements crashes with var and non-var expressions in IN clause

From: Sami Imseih <[email-masked]>
Date: Thu, 15 Jan 2026 14:53:20 -0600

> As far as I recall it was an
> intentional design decision, and to adjust newa->list_end in such
> scenarios we need to solve the original problem of finding an end
> location of any arbitrary expression,

I'm not sure I follow. How would we adjust newa->list_end?

> > > * Independently from that, it sounds like a good idea to have protection
> > >   from overlapping constants when generating normalized query. It could
> > >   be done in the same way as the previous bug was fixed. In
> > >   fill_in_constant_lengths we currently check for duplicated constants:
> > >
> > >     locs[i].location == locs[i - 1].location
> > >
> > >   then set length = -1 for those. I think it's worth extending it to
> > >   check for overlapping with the previous constant, something like:
> > >
> > >     (locs[i].location == locs[i - 1].location ||
> > >      locs[i].location <= locs[i - 1].location + locs[i - 1].length)
> >
> > Yeah, this may be a good defensive check to add, but it's
> > not going to be useful for this issue.
>
> It is, the proposed change helps to avoid the crash pointed out in this
> thread. It might not be the right solution for the reasons discussed so
> far, but as a general defensive mechanism makes total sense to me (maybe
> with an assert to highlight any potential future problem).

Yeah, we should not assume this is not expected behavior. Here is one
from the regress tests in which overlaps can occur:
```
CREATE TABLE shighway (
        surface        text
    ) INHERITS (road);

INSERT INTO shighway
       SELECT a.*, 'asphalt'
       FROM road a, road b
       WHERE a.name ~ 'State Hwy.*';
```

--
Sami Imseih
Amazon Web Services (AWS)

---

From: Michael Paquier <[email-masked]>
Date: Mon, 19 Jan 2026 17:14:46 +0900

> I'm not sure I follow. How would we adjust newa->list_end?

I may be missing something, of course, but Dmitry's message reads as
follows to me:
"It was a design choice to track the start and end locations because
we needed that for arrays, and resetting the locations if we have Vars
in the list like you are suggesting is OK by me."

I am going to re-read a bit more the area and think about a couple of
patterns to test, but I think that your suggested solution should be
OK to disable the list squashing as you are suggesting in this case:
there is nothing we can really do, and IMO that would still be OK for
most users because squashing has been designed for non-Var lists as
far as I know.  This is a rare pattern for long lists in IN arrays, as
well.  I'll sleep on it for now.
--
Michael

---

From: Dmitry Dolgov <[email-masked]>
Date: Mon, 19 Jan 2026 10:24:41 +0100

> On Mon, Jan 19, 2026 at 05:14:46PM +0900, Michael Paquier wrote:

Yep, I concur the current approach is fine. What I was saying about
adjusting newa->list_end is just an ideal and at the moment only
hypothetical scenario, where we could deduce end location of the new
list based on its nested elements. Currently there are no mechanism to
achieve that, so maybe in the future.

---

From: Michael Paquier <[email-masked]>
Date: Tue, 20 Jan 2026 08:12:15 +0900

> achieve that, so maybe in the future.

Okay, applied that down to v18 after a second lookup and a tweak to
the proposed comment.
--
Michael