Re: REPACK CONCURRENTLY fails on tables with generated columns

Alvaro Herrera <alvherre(at)kurilemu(dot)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