| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, shihao zhong <zhong950419(at)gmail(dot)com>, Radim Marek <radim(at)boringsql(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes |
| Date: | 2026-10-07 15:40:38 |
| Message-ID: | asZn9n7igh0_nXqc@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2026-10-07 15:41:19 | Re: [PG19] Wrong results from NOT NULL-based expression simplification |
| Previous Message | Nazir Bilal Yavuz | 2026-10-07 15:35:18 | Adding init-po and update-po targets to the meson build system |