Whole row var issue

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Whole row var issue
Date: 2026-08-05 23:33:34
Message-ID: CAH2-WznHo4b+6AmAj0GZ0jXqDSK69MfHe8fAQwuY_01y7cVNdw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I had Claude code look for bugs in new Postgres 19 features. It
authored the test case added by the attached patch. The test fails for
me on master (but not on 18) as follows:

# SELECT x.m0, x::text FROM t_missing_wholerow x ORDER BY 1;
# - m0 | x
# -----+------------
# - 40 | (5,,40,41)
# - 40 | (6,,40,41)
# + m0 | x
# +----+----------
# + 40 | (5,,,41)
# + 40 | (6,,,41)
# (2 rows)

As you can see, when run on master the query shows m0 with the value
40 when it is read as a column (which is correct). However, the same
query also incorrectly shows that m0 contains NULL values in each
whole row value. Obviously, m0 should have the same value within each
row (in this case 40, which comes from "ADD COLUMN m0 int NOT NULL
DEFAULT 40"), regardless of how it is queried or how the underlying
value is represented on disk.

CC'ing David Rowley, because git bisect indicates this test case
starts failing at commit c456e3911.

--
Peter Geoghegan

Attachment Content-Type Size
0001-Add-a-test-for-a-missing-attribute-lost-inside-a-who.patch application/octet-stream 3.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-05 23:38:48 Re: Fix archive restore race that could unlink WAL before rename
Previous Message John Naylor 2026-08-05 22:17:16 Re: [Patch]The Case For WAL-Logging pg_upgrade