Re: REPACK (CONCURRENTLY) might keep dropped-column data

Ok, I can't add much to the implementation discussion, but I can confirm
the patch resolves both use cases I reported.

Radim

On Wed, 30 Sept 2026 at 16:41, Antonin Houska <ah(at)cybertec(dot)at> wrote:

> Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> > Hello Radim, thanks for testing!
> >
> > On 2026-Sep-30, Radim Marek wrote:
> >
> > > Aha, so on my way to office I started thinking and got more silly
> ideas,
> > > and now can confirm this is more widespread than logical subscriber use
> > > case.
> >
> > Oh, thanks for the simplified test case. We can fix this easily by
> > setting the column to null in the tuple to write out, as in the attached
> > patch.
>
> I thought of fixing this on the decoding worker side so that the dropped
> attribute values are not even written to the output file. However that
> would
> require one more forming of the tuple.
>
> > The adjust_toast_pointers() function should perhaps be renamed,
> > and the comment rewritten, since it's no longer just about toast ...
> > I didn't do that though.
>
> Maybe prepare_concurrent_update(), as it's called right before
> apply_concurrent_update()?
>
> BTW, I've noticed now that the 'relation' argument of
> adjust_toast_pointers()
> isn't used anymore. Perhaps it was used before the tuple slots have been
> introduced into the function.
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>