pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
BUG #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>
  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-07 03:06  Richard Guo <guofenglinux@gmail.com>
  parent: PG Bug reporting form <noreply@postgresql.org>
  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
^ 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-09 20:51  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Richard Guo <guofenglinux@gmail.com>
  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