Horton

Thread

Commits

  1. Fix computation of varnullingrels when const-folding field selection.

  1. BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2

    The Post Office <noreply@postgresql.org> — 2023-11-06T12:54:30Z

    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

  2. Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2

    Richard Guo <guofenglinux@gmail.com> — 2023-11-07T03:06:30Z

    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

  3. Re: BUG #18184: ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-11-09T20:51:01Z

    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