Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2026-04-22T17:23:39Z
Lists: pgsql-bugs
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
Commits
-
test_tidstore: Stabilize regression tests by sorting offsets.
- 0b3f72f8816b 17.10 landed
- cfbfdb963a42 18.4 landed
- a424e31b16ba 19 (unreleased) landed