| From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | imchifan(at)163(dot)com |
| Subject: | BUG #19883: Partition pruning errors on SubPlan inside = ANY array |
| Date: | 2026-11-11 14:04:19 |
| Message-ID: | 19883-5fe20b9d0ae341dc@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: 19883
Logged by: Qifan Liu
Email address: imchifan(at)163(dot)com
PostgreSQL version: 18.6
Operating system: Linux/amd64
Description:
On PostgreSQL 18.6 on Linux/amd64, a SELECT against a range-partitioned
table fails with `ERROR: SubPlan found with no parent plan` when an `= ANY`
array element contains an uncorrelated SubPlan whose expression evaluates to
NULL.
The predicate is valid SQL and should return no rows. `NULL::integer IN
(SELECT v ...)` evaluates to NULL, its integer cast remains NULL, and
comparison with the resulting one-element NULL array is not true for either
row. Startup partition pruning should not attempt to evaluate the SubPlan in
a context without a parent PlanState.
How to repeat:
```sql
DROP TABLE IF EXISTS items CASCADE;
DROP TABLE IF EXISTS lookup_values;
CREATE TABLE items (id integer) PARTITION BY RANGE (id);
CREATE TABLE items_low
PARTITION OF items FOR VALUES FROM (MINVALUE) TO (10);
CREATE TABLE items_high
PARTITION OF items FOR VALUES FROM (10) TO (MAXVALUE);
INSERT INTO items VALUES (1), (11);
CREATE TABLE lookup_values (v integer);
INSERT INTO lookup_values VALUES (1);
SELECT id
FROM items
WHERE id = ANY
(ARRAY[(NULL::integer IN
(SELECT v FROM lookup_values))::integer])
ORDER BY id;
DROP TABLE items CASCADE;
DROP TABLE lookup_values;
```
Save this as `reproducer.sql` and run:
```
psql -X -f reproducer.sql
```
The client reports:
```
ERROR: SubPlan found with no parent plan
```
The corresponding server log records the failing statement:
```
ERROR: SubPlan found with no parent plan
STATEMENT: SELECT id
FROM items
WHERE id = ANY
(ARRAY[(NULL::integer IN
(SELECT v FROM lookup_values))::integer])
ORDER BY id;
```
Instead, the SELECT should complete normally and return zero rows. The issue
was reproduced on PostgreSQL 18.6; no other versions were tested. This
occurs when startup partition pruning processes an `= ANY` expression whose
array contains an uncorrelated SubPlan that evaluates to NULL.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-11-11 14:06:30 | Re: BUG #19878: pg_identify_object functions expose XX000 for unsupported class IDs |
| Previous Message | PG Bug reporting form | 2026-11-11 13:53:46 | BUG #19882: Parallel HashAggregate loses worker spill statistics after Gather rescan |