MIME-Version: 1.0
References: <b97f1850-fc7b-43c4-9b04-4e97bb9e7dc0@gmail.com>
 <CAD21AoBVEcC5stzLr80RgaWuBh0EoyRQys_aeOz0ceogMVREcQ@mail.gmail.com>
 <cb7a4bad-007a-4bbe-8e4b-8ce8109c6e93@gmail.com> <CAD21AoC86nuoxy4r6G3_Ysb2y3K+0sybznRkjVq=Yc4URZUN4g@mail.gmail.com>
 <119bd418-1d7a-42c7-9270-86f3b6696399@gmail.com> <CAD21AoAit-Qp9OriVbb9c_Qebi=Cgxz0AQJu+zxQpp=_1Lt2dQ@mail.gmail.com>
 <ea7bd70e-212d-42ae-9677-72f2f5493f3c@gmail.com> <CAD21AoCmEqiQVgJc34yGK7DSQj-p-zBVrm4-PfrwYHdNkJGt5g@mail.gmail.com>
 <9dece148-3e1d-4b0f-b798-574988fe76fe@gmail.com>
In-Reply-To: <9dece148-3e1d-4b0f-b798-574988fe76fe@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Fri, 24 Apr 2026 16:23:46 -0700
Message-ID: <CAD21AoAORy3MmSxPEaRbE_BuwW3qyxsfLGj81YcOtn6gv2iJww@mail.gmail.com>
Subject: Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAD21AoAORy3MmSxPEaRbE_BuwW3qyxsfLGj81YcOtn6gv2iJww%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 22, 2026 at 10:23=E2=80=AFAM Andrei Lepikhov <lepihov@gmail.com=
> wrote:
>
> On 22/04/2026 18:51, Masahiko Sawada wrote:
> > On Fri, Apr 17, 2026 at 2:26=E2=80=AFPM Andrei Lepikhov <lepihov@gmail.=
com> wrote:
> >>
> >> On 16/04/2026 19:58, Masahiko Sawada wrote:
> > Understood. After more thoughts, I think your idea would be better.
> >
> > One thing still unclear to me is in which situation the query inthe
> > test produces an array of unsorted offset numbers. While I understand
> > it's not guaranteed that the DISTINCT clause returns the sorted
> > result, doing DISTINCT in an aggregation function is using sort-based
> > deduplication. I'd like to confirm that the queries in the test could
> > end up producing the results that violate the assertion. Is it
> > possible to do that by changing GUC parameters or something?
> No, this is part of ongoing research into Postgres Optimizer vulnerabilit=
ies. I
> used two tools: pg_pathcheck [1] and pg-chaos-mode [2]. The first tool fi=
nds
> hidden dangling pointers in pathlists, which we are currently discussing =
in
> another thread. The second is a patch that makes the cost-based decision =
random
> to help uncover hidden or unwritten coding contracts.

Thank you for the clarification!

> Both tools are experimental and not meant for core use; they are only use=
d to
> trigger potential issues. In this case, I think the query picked a costly=
 sorted
> path, which led to the crash.

Does this imply that array_agg() could return unsorted results
depending on the plan the optimizer chooses? Or is such a path
currently never selected by the optimizer?

I=E2=80=99m asking because if this scenario never occurs with the current
optimizer, it might make sense to apply the patch only to HEAD (i.e.,
for PG20). On the other hand, backpatching to PG17 might be justified,
given that DISTINCT does not guarantee sorted results in principle,
and the fix could benefit extension development on stable branches.

Regards,

--=20
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com