Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Fix tuple deformation with virtual generated NOT NULL columns
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAApHDvq6FaC441C=G4Q9fNZQ-OKmaeW8yP0YjHpjyjBeWhj3+g@mail.gmail.com>
Date: Thu, 18 Jun 2026 10:35:37 +0800
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Peter Eisentraut <peter@eisentraut.org>,
 Andres Freund <andres@anarazel.de>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A622929-A45C-4370-943A-BC76FF4CC433@gmail.com>
References: <A4BC563C-0CA3-4EF3-952A-EA41F9E5BF1E@gmail.com>
 <CAApHDvoQKY8zHb1LZBuYZBRszi0qVmTaV_zFup=A9xqRpJWMRQ@mail.gmail.com>
 <pse3eru75b5skbvc7jjrf7origavqojc6nqtwdrr7z6sjkyxfo@siklvj643v4f>
 <BB69B882-5401-45CE-919E-8A78511EDABC@gmail.com>
 <CAApHDvogTSD_G1nkJqOvO3gZFACQUCbKg6U7yBB48r5RMaR7-Q@mail.gmail.com>
 <CAApHDvrJBXEhet4=Es_wHBKdv5PCV5OGCaJOSmJexeaFqfmUHA@mail.gmail.com>
 <1151393.1781734980@sss.pgh.pa.us> <1174236.1781736349@sss.pgh.pa.us>
 <CAApHDvpE1Jx=NrwUCihrfP+Dmkfn6kUkpCZYC10Yo+wkMu3ssQ@mail.gmail.com>
 <CAApHDvq6FaC441C=G4Q9fNZQ-OKmaeW8yP0YjHpjyjBeWhj3+g@mail.gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/2A622929-A45C-4370-943A-BC76FF4CC433%40gmail.com>
Precedence: bulk


> On Jun 18, 2026, at 07:37, David Rowley <dgrowleyml@gmail.com> wrote:
>=20
> On Thu, 18 Jun 2026 at 11:06, David Rowley <dgrowleyml@gmail.com> =
wrote:
>> Just starting to look now, but I suspect that this code in
>> llvmjit_deform.c needs to be updated now that we have virtual
>> generated columns.
>=20
> I've not fully processed all this code yet. I've still not worked out
> why the loop that sets guaranteed_column_number doesn't break when it
> finds something non-guaranteed.
>=20
> Here's a draft patch I was experimenting with. It seems to fix the
> issue. I need to spend more time to check it's correct.
>=20
> David
> <fix_jit_deform_for_virtual_generated_cols.patch>

I was not aware of the JIT code before. I think the good thing is that =
the new test uncovered this JIT bug.

I tested the fix, and it seems to work. While tracing the code, I =
wondered about this part:
```
-		if (att->attnullability =3D=3D ATTNULLABLE_VALID &&
-			!att->atthasmissing &&
-			!att->attisdropped)
+		if (attr->attgenerated =3D=3D =
ATTRIBUTE_GENERATED_VIRTUAL)
+			break;
+
+		if (catt->attnullability =3D=3D ATTNULLABLE_VALID &&
+			!catt->atthasmissing &&
+			!catt->attisdropped)
 			guaranteed_column_number =3D attnum;
```

When computing guaranteed_column_number, I think we can just skip the =
virtual generated column rather than break. Using the test from Tom=E2=80=99=
s email:
```
CREATE TABLE gtest21c (a int NOT NULL, b int GENERATED ALWAYS AS (a * 2) =
VIRTUAL NOT NULL, c int NOT NULL);
```

Here, =E2=80=9Cc" is a real NOT NULL column, so we can skip =E2=80=9Cb" =
and let =E2=80=9Cc" set guaranteed_column_number. This matters for the =
later check:
```
	/*
	 * Check if it is guaranteed that all the desired attributes are =
available
	 * in the tuple (but still possibly NULL), by dint of either the =
last
	 * to-be-deformed column being NOT NULL, or subsequent ones not =
accessed
	 * here being NOT NULL.  If that's not guaranteed the tuple =
headers natt's
	 * has to be checked, and missing attributes potentially have to =
be
	 * fetched (using slot_getmissingattrs().
	 */
	if ((natts - 1) <=3D guaranteed_column_number)
	{
```

If we break at =E2=80=9Cb", then this check goes to the else branch and =
invokes the maxatt check plus slot_getmissingattrs(), even though the =
later NOT NULL =E2=80=9Cc" proves that the tuple has enough attributes.

Otherwise, the fix looks good to me.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/