BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: feasiblechart(at)gmail(dot)com
Subject: BUG #19742: `INTERSECT` under a `UNION ALL` with an empty arm fails with "could not find pathkey item t"
Date: 2026-10-03 16:17:03
Message-ID: 19742-dc403ca277cad1d3@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 19742
Logged by: Junwen AN
Email address: feasiblechart(at)gmail(dot)com
PostgreSQL version: 19beta4
Operating system: Linux
Description:

Please see the repro. Seems like a regression; 19beta4 and the current main
branch both have this error raised, but 18.6 works fine. I ran it with psql

CREATE TABLE d (a int);
INSERT INTO d VALUES (1), (1), (2), (NULL), (3);
SELECT * FROM (SELECT a FROM d INTERSECT ALL SELECT a FROM d
UNION ALL SELECT a FROM d WHERE false) s
WHERE a = 1;
-- ERROR: XX000: could not find pathkey item to sort
(prepare_sort_from_pathkeys, createplan.c)

-- 18.6: a = 1, 1
-- 19beta4 / main: ERROR: could not find pathkey item to sort
-- EXPLAIN (without ANALYZE) fails the same way: the error is raised while
planning.

Did some more digging with LLM, and it seems this works fine
-- ============ workaround: the same query without a sorted SetOp
============
SET enable_sort = off; -- or enable_hashagg = on with statistics
that favour hashing
SELECT * FROM (SELECT a FROM d INTERSECT ALL SELECT a FROM d
UNION ALL SELECT a FROM d WHERE false) s
WHERE a = 1; -- 1, 1 (HashSetOp Intersect All)
RESET enable_sort;

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-10-03 21:34:45 Re: BUG #19741: `avg(double precision)` overflows on cancelling finite inputs whose mean is representable
Previous Message Victor Rusaleev 2026-10-03 10:17:20 Subject: Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows