MIME-Version: 1.0
References: <A4BC563C-0CA3-4EF3-952A-EA41F9E5BF1E@gmail.com>
 <CAApHDvoQKY8zHb1LZBuYZBRszi0qVmTaV_zFup=A9xqRpJWMRQ@mail.gmail.com>
 <pse3eru75b5skbvc7jjrf7origavqojc6nqtwdrr7z6sjkyxfo@siklvj643v4f>
 <BB69B882-5401-45CE-919E-8A78511EDABC@gmail.com>
In-Reply-To: <BB69B882-5401-45CE-919E-8A78511EDABC@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 12 Jun 2026 16:26:41 +1200
Message-ID: 
 <CAApHDvogTSD_G1nkJqOvO3gZFACQUCbKg6U7yBB48r5RMaR7-Q@mail.gmail.com>
Subject: Re: Fix tuple deformation with virtual generated NOT NULL columns
To: Chao Li <li.evan.chao@gmail.com>, Peter Eisentraut <peter@eisentraut.org>
Cc: Andres Freund <andres@anarazel.de>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvogTSD_G1nkJqOvO3gZFACQUCbKg6U7yBB48r5RMaR7-Q%40mail.gmail.com>
Precedence: bulk

On Tue, 9 Jun 2026 at 14:20, Chao Li <li.evan.chao@gmail.com> wrote:
> > On Jun 8, 2026, at 21:01, Andres Freund <andres@anarazel.de> wrote:
> > Seems like a test for some of this would be good too?

> Okay, I tried to add a test matching my repro. With this test in place, I reverted the fix and ran make check; it failed by hitting the Assert David added:
> ```
> TRAP: failed Assert("first_null_attr(tup->t_bits, natts) >= firstNullAttr"), File: "execTuples.c", Line: 1083, PID: 65804

I was on the fence about that test as I felt it was mostly
highlighting that there was a bug once with that particular case, and
didn't feel like it did much to prevent future omissions from
TupleDescFinalize(). I felt the Assert would help highlight future
stuff.

However, I don't object to adding the test if others feel it's
worthwhile, but on looking at the patch, there are a couple of things
that stand out.

1. Nothing has been done for the comment at the top of the file that
says "-- keep these tests aligned with generated_stored.sql".  It
looks like there have been quite a few commits already which have
neglected this. Maybe that means we should do away with the comment
rather than try to align the two.
2. I can't quite figure out the pattern in these tests for dropping vs
not dropping the tables at the end of the test. Many tests do DROP
TABLE and a large number of others don't bother. What's meant to be
happening here?

I've added Peter as I think it was his intention to keep these tests
aligned with generated_stored.sql.

David