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

Radim Marek <radim(at)boringsql(dot)com> wrote:

> Hi Shihao, thank you for the confirmation. I wasn't aware of the enhancements series.
>
> It's definitely not a performance issue in the doc; rathe a resource limit. Since 19 will go with this limitation I attached a small doc patch
> about this. Hope I got the use of 'other' correctly based on current version https://www.postgresql.org/docs/19/sql-repack.html

It's unfortunate that REPACK is probably the only command that exercises this
combo CID limit. However, there can be other limits, e.g. REPACK being unable
to catch up if the change rate is too high, excessive usage of disk for the
decoded changes, etc.

I think that the most important thing for the user to know is that the purpose
of REPACK is to improve performance (via bloat removal and/or clustering),
whereas "failsafe VACUUM" (i.e. VACUUM with INDEX_CLEANUP set to off) should
be used to avoid the risk of XID wraparound. This kind of VACCUM is probably
much faster and less likely to fail.

I don't have a good idea about the wording right now.

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