Re: BUG #19684: Assertion in tuplesort_begin_heap() falsified by parallel plan with sort

Hi Ayush,

Thanks for the patch. I applied it and tested against the repro:
On unpatched master (with --enable-cassert), it crashes with the exact
reported assertion (Assert("nkeys > 0") in tuplesortvariants.c:195). With
your patch applied, the same query completes cleanly with (0 rows), no
crash.

On the Assert(pathkeys != NIL) question:
I tested it directly: with your guard temporarily removed but the assert
added to create_sort_path(), the same bug is caught immediately at
pathnode.c:2915 instead of downstream at tuplesortvariants.c:195. With the
guard back in place and the assert added, all 240 regression tests pass.

So the assert is safe to add, and it would make failures easier to diagnose
if some future caller makes the same mistake. That said, I'm not sure if
it's necessary, your guard already fixes the actual bug at its source, and
this call site is the only one that had the problem.

Regards,
Samriddha

On Sat, Sep 12, 2026 at 10:15 PM Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
> On Sat, 12 Sept 2026 at 20:33, PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
> >
> > The following bug has been logged on the website:
> >
> > Bug reference: 19684
> > Logged by: Alexander Lakhin
> > Email address: exclusion(at)gmail(dot)com
> > PostgreSQL version: 19beta3
> > Operating system: Ubuntu 24.04
> > Description:
> >
> > The following script:
> > SET cpu_tuple_cost = 1000;
> > SET min_parallel_table_scan_size = 1;
> >
> > CREATE TABLE t(i int);
> > SELECT FROM t UNION SELECT FROM t;
> >
> > triggers:
> > TRAP: failed Assert("nkeys > 0"), File: "tuplesortvariants.c", Line: 195,
> > PID: 1465852
> >
> > EXPLAIN shows:
> > QUERY PLAN
> >
> -----------------------------------------------------------------------------------------------
> > Unique (cost=3188844.07..3188856.82 rows=2 width=0)
> > -> Sort (cost=3188844.07..3188856.82 rows=5100 width=0)
> > -> Gather (cost=1000.00..3188530.00 rows=5100 width=0)
> > Workers Planned: 2
> > -> Parallel Append (cost=0.00..3187020.00 rows=2124
> > width=0)
> > -> Parallel Seq Scan on t (cost=0.00..1062510.00
> > rows=1062 width=0)
> > -> Parallel Seq Scan on t t_1
> (cost=0.00..1062510.00
> > rows=1062 width=0)
> >
> > Without asserts enabled, SELECT succeeds and EXPLAIN (ANALYZE) shows the
> > same plan.
> >
> > Reproduced starting from 66c0185a3/12933dc60.
>
> Thanks for the report!
>
> It looks like the Gather path is missing the check already used for the
> non-parallel Append path. For a zero-column UNION, groupList is NIL, but
> the Gather path still creates a Sort and eventually calls
> tuplesort_begin_heap() with zero sort keys.
>
> I added the same "if (groupList != NIL)" condition around
> create_sort_path() for the Gather path. With the patch, the reported test
> and a variant using a populated table both complete successfully.
>
> I wonder if we should also add an Assert(pathkeys != NIL) inside
> create_sort_path()?
>
> Regards,
> Ayush
>