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

From Antonin Houska
Subject Re: REPACK CONCURRENTLY fails on tables with generated columns
Date
Msg-id 135099.1783099577@localhost
Whole thread
In response to Re: REPACK CONCURRENTLY fails on tables with generated columns  (Alvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
Alvaro Herrera <alvherre@kurilemu.de> wrote:

> 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.

Good point, thanks.

> 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.

+1

--
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: Zsolt Parragi
Date:
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01