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)
