RE: Adding REPACK [concurrently]

> -----Original Message-----
> From: Antonin Houska <ah(at)cybertec(dot)at>
> Sent: Friday, April 10, 2026 9:22 PM
> To: Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com>
> Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>; Amit Kapila
> <amit(dot)kapila16(at)gmail(dot)com>; Kuroda, Hayato/黒田 隼人
> <kuroda(dot)hayato(at)fujitsu(dot)com>; Srinath Reddy Sadipiralla
> <srinath2133(at)gmail(dot)com>; Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>;
> Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>; Pg Hackers
> <pgsql-hackers(at)lists(dot)postgresql(dot)org>; Robert Treat <rob(at)xzilla(dot)net>
> Subject: Re: Adding REPACK [concurrently]
>
> Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> > When testing REPACK concurrently, I noticed that all WALs are retained
> > from the moment REPACK begins copying data to the new table until the
> > command finishes replaying concurrent changes on the new table and
> > stops the repack decoding worker.
> >
> > I understand the reason: the REPACK command itself starts a
> > long-running transaction, and logical decoding does not advance
> > restart_lsn beyond the oldest running transaction's start position. As
> > a result, slot.restart_lsn remains unchanged, preventing the checkpointer
> from recycling WALs.
>
> I think you're right, sorry for the omission.
>
> > IIUC, REPACK without using concurrent option does not have this issue.
>
> It does not have the WAL recycling issue because it does not need to read
> WAL. However it also runs in a long transaction. Even though it does not need
> XID for the actual heap rewriting, it gets one at the moment it locks the table
> using AccessExclusiveLock (which is at the very beginning).
>
> > Given that we do not restart a REPACK, I think the repack decoding
> > worker should be able to advance restart_lsn each time after writing
> > changes (similar to how a physical slot behaves). To illustrate this,
> > I've written a patch (attached) that implements this approach, and it works
> fine for me.
>
> LGTM, thanks!
>

Thanks for reviewing!

After listening to the REPACK talk at pgconf.dev this year, I understand that
WAL accumulation during REPACK CONCURRENTLY is not intended behavior. I think we
can consider fixing this in the current release. Attached is the rebased
patch, with comments adjusted based on Chao Li's comments.

Best Regards,
Hou zj