Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" |
| Дата | |
| Msg-id | 9dece148-3e1d-4b0f-b798-574988fe76fe@gmail.com обсуждение |
| Ответ на | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
|
| Список | 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
В списке pgsql-bugs по дате отправления: