Re: REPACK CONCURRENTLY fails on tables with generated columns - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: REPACK CONCURRENTLY fails on tables with generated columns
Date
Msg-id akeN0fZ_Dc4SSjN0@alvherre.pgsql
Whole thread
In response to Re: REPACK CONCURRENTLY fails on tables with generated columns  (Ewan Young <kdbase.hack@gmail.com>)
Responses Re: REPACK CONCURRENTLY fails on tables with generated columns
Re: REPACK CONCURRENTLY fails on tables with generated columns
List pgsql-hackers
Hello,

On 2026-Jun-22, Ewan Young wrote:

> I applied the patch and ran it through an injection-point reproducer
> (cassert). Without the fix the bug reproduces (ERROR: no generation
> expression found for column number 3 ...); with it, REPACK CONCURRENTLY
> succeeds under a concurrent non-HOT UPDATE for a STORED generated column, an
> index directly on the generated column, and a VIRTUAL column, with correct
> values afterwards. Your repack.spec change passes.
> 
> The approach is right and I've confirmed it fixes the bug, so +1 from me in
> this direction.

Cool, thanks for reviewing -- I have pushed this fix, with some
stylistic changes and one bigger change: these catalog rows are only
needed in concurrent mode, so there was no reason to copy them in the
other case.  So I restricted the copying to that case.

I've been looking at the other proposed change, and I agree with it.
Here's it, again with some style changes, and only one other proposed
change: for setting up updatedCols, ignore dropped columns.  I don't
think this should change anything in practice, but it just feels wrong
to claim that a dropped column is being changed by an update.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Attachment

pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: Proposal: INSERT ... BY NAME
Next
From: Tomas Vondra
Date:
Subject: Re: Is there value in having optimizer stats for joins/foreignkeys?