Incremental Sort crash on a rescan that becomes bounded

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, jtc331(at)gmail(dot)com, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Incremental Sort crash on a rescan that becomes bounded
Date: 2026-11-15 04:15:47
Message-ID: CAGRkXqRXMiR9EBxBT7VEF0jF_9NJAxVcGrtRdsTZOfNkHfVtsg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

This fails an assertion in tuplesort_set_bound():

set enable_seqscan = off;
set enable_bitmapscan = off;
select o.n, count(*) from (values (null::int), (3)) o(n),
lateral (select unique1 from tenk1 where hundred < 2
order by hundred, unique1 limit o.n) s
group by o.n;

Incremental Sort creates its sort states on the first scan and reuses
them on rescan. They only allow a bound if the first scan was bounded,
so a later scan that sets a bound fails the assertion. Since 17 such a
state uses a Bump context. A bounded sort frees the tuples it throws
away, which Bump can't do. So release builds can crash too.

The attached patch ends the sort state on such a rescan. The second
patch is the version for 15.

Thanks,
Shihao

Attachment Content-Type Size
v1-0001-Fix-Incremental-Sort-rescan-that-becomes-bounded.patch text/x-patch 6.4 KB
REL_15-v1-0001-Fix-Incremental-Sort-rescan-that-becomes-bounded.patch text/x-patch 6.4 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-11-15 04:22:59 Re: Index drops during phase 1 of REINDEX CONCURRENTLY
Previous Message shihao zhong 2026-11-15 04:06:38 Re: Prevent foreign key references to unlogged partitions