From 7fb29fdd109563a0c981182d91b034c43f55098a Mon Sep 17 00:00:00 2001
From: Radim Marek <radim@boringsql.com>
Date: Sat, 26 Sep 2026 09:02:28 +0200
Subject: [PATCH] doc: Mention memory use and change limit of REPACK
 (CONCURRENTLY)

REPACK (CONCURRENTLY) needs a bit of backend memory for every row that
other transactions update or delete while it runs, and it fails once
there are more than about 100 million of them.  Neither is mentioned in
the docs, so add a short note.

Discussion: https://postgr.es/m/CAJgoLk+dodrwuwCuXERGYwgjQzSwrKd+xgitYrL32oWDt39zvA@mail.gmail.com
---
 doc/src/sgml/ref/repack.sgml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/doc/src/sgml/ref/repack.sgml b/doc/src/sgml/ref/repack.sgml
index 346cba89c90..b65f9620006 100644
--- a/doc/src/sgml/ref/repack.sgml
+++ b/doc/src/sgml/ref/repack.sgml
@@ -259,6 +259,13 @@ REPACK [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] USING
        are also stored separately in a temporary file, until they can be
        processed.
       </para>
+      <para>
+       Each row that other transactions update or delete during
+       <command>REPACK (CONCURRENTLY)</command> also takes a small amount of
+       backend memory, not limited by <xref linkend="guc-maintenance-work-mem"/>.
+       The command cannot complete if more than about 100 million rows are
+       changed this way.
+      </para>
      </note>
 
      <para>
-- 
2.55.0