pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
3+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2023-11-09 36f5594c0f 6bf2efb382 Fix computation of varnullingrels when const-folding field selection.
* BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
@ 2023-11-06 12:54 PG Bug reporting form <noreply@postgresql.org>
2023-11-07 03:06 ` Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: PG Bug reporting form @ 2023-11-06 12:54 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: marian.krucina@linuxbox.cz
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
2023-11-06 12:54 BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 PG Bug reporting form <noreply@postgresql.org>
@ 2023-11-07 03:06 ` Richard Guo <guofenglinux@gmail.com>
2023-11-09 20:51 ` Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Richard Guo @ 2023-11-07 03:06 UTC (permalink / raw)
To: marian.krucina@linuxbox.cz; pgsql-bugs@lists.postgresql.org
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
Attachments:
v1-0001-Fix-mismatched-nullingrels-when-inlining-functions.patch (application/octet-stream, 3.6K) download
From d6c782dde374cc0ff1b1feae7d751066a1db8417 Mon Sep 17 00:00:00 2001
From: Richard Guo <guofenglinux@gmail.com>
Date: Tue, 7 Nov 2023 10:50:00 +0800
Subject: [PATCH v1] Fix mismatched nullingrels when inlining functions
When we optimize field selection from a whole-row Var into a simple Var
while simplifying functions, we failed to propagate the nullingrels into
the new Var. This patch fixes that.
Per report from Marian Krucina in BUG #18184
---
src/backend/optimizer/util/clauses.c | 20 ++++++++++++++------
src/test/regress/expected/join.out | 20 ++++++++++++++++++++
src/test/regress/sql/join.sql | 10 ++++++++++
3 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index da258968b8..6b3e712905 100644
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -3296,12 +3296,20 @@ eval_const_expressions_mutator(Node *node,
fselect->resulttype,
fselect->resulttypmod,
fselect->resultcollid))
- return (Node *) makeVar(((Var *) arg)->varno,
- fselect->fieldnum,
- fselect->resulttype,
- fselect->resulttypmod,
- fselect->resultcollid,
- ((Var *) arg)->varlevelsup);
+ {
+ Var *newvar;
+
+ newvar = makeVar(((Var *) arg)->varno,
+ fselect->fieldnum,
+ fselect->resulttype,
+ fselect->resulttypmod,
+ fselect->resultcollid,
+ ((Var *) arg)->varlevelsup);
+
+ newvar->varnullingrels = ((Var *) arg)->varnullingrels;
+
+ return (Node *) newvar;
+ }
}
if (arg && IsA(arg, RowExpr))
{
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 892ea5f170..52fe18d5fa 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -2687,6 +2687,26 @@ select * from onek t1
Filter: (two = t2.two)
(11 rows)
+--
+-- check for correct handling of nullingrels when simplifying functions
+--
+create function f_immutable_nullingrels(t onek) returns text as
+$$ select t.unique1::text; $$ language sql immutable;
+explain (costs off)
+select f_immutable_nullingrels(t2) from onek t1
+ left join onek t2 on t1.unique1 = t2.unique1
+ left join onek t3 on true;
+ QUERY PLAN
+-----------------------------------------------------------
+ Nested Loop Left Join
+ -> Merge Left Join
+ Merge Cond: (t1.unique1 = t2.unique1)
+ -> Index Only Scan using onek_unique1 on onek t1
+ -> Index Only Scan using onek_unique1 on onek t2
+ -> Materialize
+ -> Index Only Scan using onek_hundred on onek t3
+(7 rows)
+
--
-- check a case where we formerly got confused by conflicting sort orders
-- in redundant merge join path keys
diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql
index 559c36dc07..80169f9efb 100644
--- a/src/test/regress/sql/join.sql
+++ b/src/test/regress/sql/join.sql
@@ -550,6 +550,16 @@ select * from onek t1
(select * from onek t3 where t3.two = t2.two offset 0) s
on t2.unique1 = 1;
+--
+-- check for correct handling of nullingrels when simplifying functions
+--
+create function f_immutable_nullingrels(t onek) returns text as
+$$ select t.unique1::text; $$ language sql immutable;
+explain (costs off)
+select f_immutable_nullingrels(t2) from onek t1
+ left join onek t2 on t1.unique1 = t2.unique1
+ left join onek t3 on true;
+
--
-- check a case where we formerly got confused by conflicting sort orders
-- in redundant merge join path keys
--
2.31.0
* Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2
2023-11-06 12:54 BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 PG Bug reporting form <noreply@postgresql.org>
2023-11-07 03:06 ` Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 Richard Guo <guofenglinux@gmail.com>
@ 2023-11-09 20:51 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2023-11-09 20:51 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: marian.krucina@linuxbox.cz; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2023-11-09 20:51 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-11-06 12:54 BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 PG Bug reporting form <noreply@postgresql.org>
2023-11-07 03:06 ` Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 Richard Guo <guofenglinux@gmail.com>
2023-11-09 20:51 ` Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2 Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox