> -----Original Message----- > From: Antonin Houska <[email protected]> > Sent: Friday, April 10, 2026 9:22 PM > To: Hou, Zhijie/侯 志杰 <[email protected]> > Cc: Alvaro Herrera <[email protected]>; Amit Kapila > <[email protected]>; Kuroda, Hayato/黒田 隼人 > <[email protected]>; Srinath Reddy Sadipiralla > <[email protected]>; Mihail Nikalayeu <[email protected]>; > Matthias van de Meent <[email protected]>; Pg Hackers > <[email protected]>; Robert Treat <[email protected]> > Subject: Re: Adding REPACK [concurrently] > > Zhijie Hou (Fujitsu) <[email protected]> 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
v2-0001-Allow-old-WAL-recycling-during-REPACK-CONCURRENTL.patch
Description: v2-0001-Allow-old-WAL-recycling-during-REPACK-CONCURRENTL.patch
