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)
