Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Date: 2026-04-21 14:59:56
Message-ID: CA+renyWk7kVsZJPZKzN95mYkO7S=hDUx=+fUPtbg9qFqeepCpg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 20, 2026 at 8:58 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> + updatedCols =
> + bms_add_member(updatedCols,
> + rangeAttno - FirstLowInvalidHeapAttributeNumber);
>
> Here, use "perminfo->updatedCols" not "updatedCols", otherwise segfault.
> The attached diff based on v5, fixes this issue.
>
> +ALTER TABLE temporal_partitioned_3 ADD COLUMN range_len int GENERATED
> ALWAYS AS (upper(valid_at) - lower(valid_at)) STORED;
> Slightly refactoring the tests will allow for easier comparison of
> range_len values.

I can't reproduce a segfault. I don't see how that code would lead to
one. Can you share what you're doing to cause it? Simply running the
regression tests doesn't do it for me.

The v5 patch has quite a lot of code shared between both branches. I
was trying to avoid that in the v5 patch. Is there any way to clean it
up?

I like the how the test change makes it easy to verify the range_len column.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2026-04-21 15:07:25 Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Previous Message Tatsuya Kawata 2026-04-21 14:56:45 Re: [PATCH] Doc: Fix missing func_signature role in pg_get_tablespace_ddl entry