Request a Demo
Home   >   mailing lists

Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
Date
Msg-id asZn9n7igh0_nXqc@nathan
Whole thread
In response to Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes  (Alvaro Herrera <alvherre@kurilemu.de>)
Responses Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
List pgsql-hackers
Tree view 
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

pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Adding init-po and update-po targets to the meson build system
Next
From: Melanie Plageman
Date:
Subject: Re: [PG19] Wrong results from NOT NULL-based expression simplification