On Wed, Apr 22, 2026 at 10:23 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> On 22/04/2026 18:51, Masahiko Sawada wrote:
> > On Fri, Apr 17, 2026 at 2:26 PM 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 vulnerabilities. I
> used two tools: pg_pathcheck [1] and pg-chaos-mode [2]. The first tool finds
> 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 used 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’m 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,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
