Re: Adding REPACK [concurrently]

On 2026-Feb-25, Antonin Houska wrote:

> Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> 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)