Message-ID: <9dece148-3e1d-4b0f-b798-574988fe76fe@gmail.com>
Date: Wed, 22 Apr 2026 19:23:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File:
 "tidstore.c"
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
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>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CAD21AoCmEqiQVgJc34yGK7DSQj-p-zBVrm4-PfrwYHdNkJGt5g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/9dece148-3e1d-4b0f-b798-574988fe76fe%40gmail.com>
Precedence: bulk

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.
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.

[1] https://github.com/danolivo/pg_pathcheck
[2] https://github.com/danolivo/pg-chaos-test

-- 
regards, Andrei Lepikhov,
pgEdge