Re: BUG #19784: "no relation entry for relid 1" when costing = ANY (<array expr over max(col)>) in a MinMaxAggPath

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: BUG #19784: "no relation entry for relid 1" when costing = ANY (<array expr over max(col)>) in a MinMaxAggPath
Date: 2026-10-23 02:32:47
Message-ID: CAGRkXqSqDDwfPFyvpbb7APi3KM0SEH7yX9zbZUG9_yyhHMFjKA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom,

> What is bothering me a bit here is that this is surely not the only
> estimator routine that calls examine_variable, so why don't we
> have other problems?

The range <@ support function costs its element expression during
eval_const_expressions. So this fails on master too:

CREATE TABLE at (a int4[]);
SELECT * FROM at WHERE (1 = ANY (a))::int <@ int4range(0, 5);
ERROR: no relation entry for relid 1

Your patch fixes ^^^^^, since simple_rel_array is still NULL there.

It does not fix this:

CREATE TABLE ei (a int4[]);
CREATE INDEX ON ei
((((1 = ANY (a))::int + (2 = ANY (a))::int) <@ int4range(0, 5)));
SELECT * FROM ei;
ERROR: no relation entry for relid 1

The attached patch on top of yours passes NULL as root to
cost_qual_eval_node() in find_simplified_clause(), like aba8f61c3 did
for cost_subplan(). It fixes all the attached cases.

Thanks,
Shihao

Attachment Content-Type Size
nocfbot-range-support-null-root.patch application/octet-stream 1.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message shihao zhong 2026-10-23 03:01:05 Re: BUG #19775: Incremental backup without data checksums restores a stale visibility map page after VACUUM truncati
Previous Message Fujii Masao 2026-10-23 02:01:29 Re: BUG #19775: Incremental backup without data checksums restores a stale visibility map page after VACUUM truncati