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 CAJTYsWXnTQgH3m5a_bc4C+pumKj_fiEs4ZqaCjs8L8wvcrsy3g@mail.gmail.com
Whole thread
In response to Re: BUG #19684: Assertion in tuplesort_begin_heap() falsified by parallel plan with sort  (Ayush Tiwari <ayushtiwari.slg01@gmail.com>)
List pgsql-bugs
On Sun, 13 Sept 2026 at 12:06, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
>
> 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 is v3 with a minor correction to the regression test, so that
it exercises the affected path. The code change is unchanged.

Regards,
Ayush

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #19687: ALTER SEQUENCE provokes error XX001 could not read blocks
Next
From: Grigorev Jurij
Date:
Subject: Postmaster crashes on SIGHUP when oauth_validator_libraries holds only whitespace