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

The following bug has been logged on the website:

Bug reference: 18184
Logged by: Marian Krucina
Email address: marian(dot)krucina(at)linuxbox(dot)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(at)postgresql(dot)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

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Mon, Nov 6, 2023 at 10:39 PM PG Bug reporting form <
> noreply(at)postgresql(dot)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