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