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. 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.

I have revamped the reference page for REPACK rather heavily. What do
you think of this? I attach the HTML for easy reading.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/