Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes

On 2026-Oct-06, Antonin Houska wrote:

> I thought about this documentation update last week and wasn't sure it needs
> to be that exact about how much memory is consumed per changed tuple.

True. I do want to clarify that the amount of memory used is not the
size of the tuples, though.

> I think
> we should rather encourage users to do monitoring in genaral: besides memory,
> the system can run out of disk space (REPACK w/o CONCURRENTLY also creates a
> copy of the table, but it's probably not used for big tables due to the
> stronger lock). Besides that, REPACK runs in a single transaction, so it might
> hold the xmin horizon(s) for too long (like any other long-running
> transactions). Finally, the processing of the concurrent changes might not be
> fast enough, in which case the AccessExclusiveLock may be needed for
> surprisingly long time.

Hmm, I'll see what I can come up with. Note you say "it might hold the
xmin horizon like any other long-running transactions", but that's not
true for VACUUM, so I think it's worth pointing it out explicitly, since
it's a clear disadvantage of REPACK.

> The paragraph about REPACK vs VACUUM LGTM.

Great, thanks for looking.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Tiene valor aquel que admite que es un cobarde" (Fernandel)