Re: Fix tuple deformation with virtual generated NOT NULL columns

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: Fix tuple deformation with virtual generated NOT NULL columns
Date: 2026-06-04 10:30:09
Message-ID: A26008F4-C500-453B-9A3C-CACC3BB3607F@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jun 4, 2026, at 17:32, cca5507 <cca5507(at)qq(dot)com> wrote:
>
>> While testing "Optimize tuple deformation”, I found a bug:
>> ```
>> evantest=# create table t (a int not null,
>> evantest(# g int generated always as (a+1) virtual not null,
>> evantest(# b int not null);
>> CREATE TABLE
>> evantest=# insert into t (a, b) values (10, 20);
>> INSERT 0 1
>> evantest=# select a, g, b from t;
>> a | g | b
>> ----+----+---
>> 10 | 11 | 0
>> (1 row)
>> ```
>
> Nice catch! I can reproduce this bug on master. Some comments about the fix:
>
> I find that a virtual generated column is stored as a null in heap tuple, so I think
> we should stop setting 'attcacheoff' when we see a virtual generated column in
> TupleDescFinalize(), or we will set wrong 'attcacheoff' value. But it seems that
> we don't use these wrong value because we can only use 'attcacheoff' up until
> the first NULL.
>
> --
> Regards,
> ChangAo Chen

Hi ChangAo,

Thanks for your review. Please see v2 that addressed your comment.

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

Attachment Content-Type Size
v2-0001-Fix-tuple-deformation-with-virtual-generated-NOT-.patch application/octet-stream 4.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-06-04 10:35:06 Re: Proposal: Conflict log history table for Logical Replication
Previous Message vellaipandiyan sm 2026-06-04 10:08:19 [PATCH] DOCS: Distinguish table and index storage parameters