On Wed, Oct 07, 2026 at 02:26:54PM +0200, Alvaro Herrera wrote:
> Pushed this. Thanks for the reviews!
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?
--
nathan
