Re: BUG #19684: Assertion in tuplesort_begin_heap() falsified by parallel plan with sort - Mailing list pgsql-bugs

From Ayush Tiwari
Subject Re: BUG #19684: Assertion in tuplesort_begin_heap() falsified by parallel plan with sort
Date
Msg-id CAJTYsWW4nJ++hX_DRspfPgiPFYg0iiRKUB_6PgQXjJzZqYHO1Q@mail.gmail.com
Whole thread
Responses Re: BUG #19684: Assertion in tuplesort_begin_heap() falsified by parallel plan with sort
List pgsql-bugs
Hi,

On Sat, 12 Sept 2026 at 22:15, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
>
> Hi,
>
> On Sat, 12 Sept 2026 at 20:33, PG Bug reporting form
> <noreply@postgresql.org> wrote:
> >
> > The following bug has been logged on the website:
> >
> > Bug reference:      19684
> > Logged by:          Alexander Lakhin
> > Email address:      exclusion@gmail.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()?

Attached v2.

The code change is unchanged.  I adjusted the regression query because v1
caused unrelated Gather advice warnings under test_plan_advice.

Regards,
Ayush

Attachment

pgsql-bugs by date:

Previous
From: Ayush Tiwari
Date:
Subject: Re: BUG #19685: START_REPLICATION accepts an overflowing LSN component
Next
From: PG Bug reporting form
Date:
Subject: BUG #19686: Rolling back SET TABLESPACE + INSERT leads to index corruption