Horton

Re: TupleDescAttr bounds checks

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-20T16:46:07Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 20, 2026 at 12:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I had just come to the same conclusion about why grison is failing.

> Hmm, I had a rougher version of this analysis (and an analysis of some
> the other failures) on an email I sent yesterday on the pg_plan_advice
> thread. Based on this email and another one you sent, I'm guessing you
> either didn't see that email or maybe even didn't get a copy of it for
> some reason.

I did see that, but it read to me that you were just guessing at that
time.  This morning I put Asserts into indexcmds.c that verified that
it was trying to access the tupledesc for attno zero, and that proves
there is a bug there.  It also seems like a plausible explanation for
why only one machine has exhibited the failure.  (Your 0002 is a
better version of said Asserts.)

			regards, tom lane

Commits

  1. Avoid unsafe access to negative index in a TupleDesc.

  2. Disallow system columns in COPY FROM WHERE conditions.

  3. Add a test for creating an index on a whole-row expression.

  4. Bounds-check access to TupleDescAttr with an Assert.

  5. Prevent spurious "indexes on virtual generated columns are not supported".