Thread: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
From
PG Bug reporting form
Date:
The following bug has been logged on the website: Bug reference: 18184 Logged by: Marian Krucina Email address: marian.krucina@linuxbox.cz PostgreSQL version: 16.0 Operating system: AlmaLinux release 9.0 Description: Hi, We found a bug in PostgreSQL 16. I have simplified the case: CREATE TABLE table1(table1_id serial, i int); CREATE TABLE table2(table2_id serial, i int); CREATE TABLE table3(table3_id serial, i int, a1 TEXT, a2 TEXT, a3 TEXT, a4 TEXT, a5 TEXT, a6 TEXT, a7 TEXT); CREATE INDEX ON table3 (table3_id); INSERT INTO table1 (i) SELECT generate_series(1, 1000); INSERT INTO table2 (i) SELECT generate_series(1, 1000); INSERT INTO table3 (i, a1, a2, a3, a4, a5, a6, a7) SELECT generate_series(1, 1000), random()::TEXT, random()::TEXT, random()::TEXT, random()::TEXT, random()::TEXT, random()::TEXT, random()::TEXT; CREATE OR REPLACE FUNCTION function1(x table1) RETURNS text LANGUAGE sql IMMUTABLE AS $function$ SELECT CASE WHEN 10 < x.i THEN 'aaa' ELSE 'bbb' END ; $function$; SELECT function1(table1) FROM table2 LEFT JOIN table1 ON table1_id = table2_id LEFT JOIN LATERAL (SELECT 1 FROM table3) AS tx3 ON (true) LIMIT 5; ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 SELECT version(); version ---------------------------------------------------------------------------------------------------------- PostgreSQL 16.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4), 64-bit Thank you, Marian Krucina
On Mon, Nov 6, 2023 at 10:39 PM PG Bug reporting form <noreply@postgresql.org> wrote:
Hi,
We found a bug in PostgreSQL 16. I have simplified the case:
SELECT
function1(table1)
FROM table2
LEFT JOIN table1 ON table1_id = table2_id
LEFT JOIN LATERAL (SELECT 1 FROM table3) AS tx3 ON (true)
LIMIT 5;
ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
Thanks for the report! This is an error message that hasn't been seen
in a long time.
It seems that when we optimize field selection from a whole-row Var into
a simple Var while simplifying functions, we fail to propagate the
nullingrels into the new Var.
Attached is a hotfix for this error. But I'm wondering if there are
other similar cases where we have mismatched nullingrels that we haven't
discovered yet. Any thoughts?
Thanks
Richard
in a long time.
It seems that when we optimize field selection from a whole-row Var into
a simple Var while simplifying functions, we fail to propagate the
nullingrels into the new Var.
Attached is a hotfix for this error. But I'm wondering if there are
other similar cases where we have mismatched nullingrels that we haven't
discovered yet. Any thoughts?
Thanks
Richard
Attachment
Richard Guo <guofenglinux@gmail.com> writes: > On Mon, Nov 6, 2023 at 10:39 PM PG Bug reporting form < > noreply@postgresql.org> wrote: >> ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 > It seems that when we optimize field selection from a whole-row Var into > a simple Var while simplifying functions, we fail to propagate the > nullingrels into the new Var. Yup, good catch! Fix pushed with a little editorializing on the test case (mainly to try to ensure cross-platform stability of its plan). > Attached is a hotfix for this error. But I'm wondering if there are > other similar cases where we have mismatched nullingrels that we haven't > discovered yet. Any thoughts? It's worrisome I agree. I looked through the other calls of makeVar() and didn't find any that seemed wrong. (There are a lot of them that are concerned with cases like manufacturing rowmark Vars, which I think are OK because we don't support FOR UPDATE on nullable rels.) Still, I wouldn't be totally surprised if we find a few more. regards, tom lane