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

Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Sep-27, shihao zhong wrote:
>
> > Here is a try with Fable, as v2 of Radim's patch.
> >
> > It adds a paragraph to Notes. REPACK is for bloat and clustering. For
> > wraparound uses VACUUM, because REPACK takes much longer and can fail
> > late.
>
> Yeah, that sounds appropriate.
>
> I think the original <note> paragraph is worth rewriting more deeply
> though rather than just adding one more paragraph; I think some of the
> things it mentions are not so relevant from the user's POV, and also I
> think we can use some small changes elsewhere in the page.
>
> What do you think of the attached? I used -U7 in `git format-patch` so
> that the surrounding can be read directly from the patch.

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.

The paragraph about REPACK vs VACUUM LGTM.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com