On 2026-Oct-07, Nathan Bossart wrote:
> We talked about this one in today's RMT meeting.
>
> Processing of these concurrent changes requires a fixed small amount of
> memory for each tuple concurrently updated or deleted, not limited by
> maintenance_work_mem; if more than about 104 million rows are
> concurrently updated or deleted during the execution of REPACK, the
> command fails.
>
> This seems like a rather low limit that will definitely affect folks in the
> field. The upthread discussion indicates that the "make REPACK
> (CONCURRENTLY) MVCC-safe" work should fix this, but could there be an
> incremental improvement that alleviates this limitation in the meantime?
The limit is caused by the dynahash used in combocid.c to store the CID
mappings. An "easy" fix for this might be to mark that allocation as
using palloc_huge() somehow. I haven't actually tried that, but I
suspect it's not without its risks. (Since I didn't test it, I don't
know either if there are any other limits beyond that one.)
I'm not really sure that 105 million tuples modified concurrently during
repack is really all that small a limitation. I mean, it's not
**huge**, but it's not tiny either. If you update 1000 tuples per
second while REPACK runs, you'd need a REPACK run that takes 28 hours to
reach the limit. I guess it's definitely not impossible to hit it, if
your workload is insane enough.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
