On 2026-Feb-25, Antonin Houska wrote: > Srinath Reddy Sadipiralla <[email protected]> wrote:
> > 2) transient table's WALs - these are generated because of > > concurrent changes done while applying the logical decoded changes > > on the new transient table, i think this won't be a problem until > > they only will get recycled but if they get archived , they are of > > no use instead they consume more space and time during the archival > > process. > > VACUUM FULL / CLUSTER also produces (a lot of) WAL, so IMO there's > nothing specific about REPACK. Yeah, I don't think there's anything we can (or should) do about this. It's just writing to the common WAL stream, which means that any non-repack concurrent load is going to be producing WAL messages interspersed with what is being done for repack. So it's not possible to skip archiving those files, or anything of the sort. In fact, these messages being written to WAL is how REPACK is going to be transmitted to replicas. (Actually, now that I think about this, I realize that I don't know how this part really works, and I should. Back to code review it is then.) -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "At least to kernel hackers, who really are human, despite occasional rumors to the contrary" (LWN.net)
