Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes

On 2026-Oct-07, Alvaro Herrera wrote:

> You're right, that was pretty hard to read. How about this, following
> Radim's suggestion?

I settled on this, which seems perfectly clear:

<para>
<command>REPACK</command> creates a temporary copy of the table and all
of its indexes, so you need free disk space at least equal to the sum
of the table size and the index sizes.
</para>

<para>
If the <literal>USING INDEX</literal> clause is given and the planner
chooses a sequential scan and sort to implement it, a temporary sort
file of up to the size of the table is needed in addition to the above.
This method is usually faster than an index scan, but if the disk space
requirement is intolerable, you can disable this choice by temporarily
setting <xref linkend="guc-enable-sort"/> to <literal>off</literal>; or
omitting <literal>USING INDEX</literal> if the table doesn't need to be
reordered.
</para>

Also, the note about REPACK being one long transaction preventing useful
vacuuming work applies to both regular one and concurrent, so it must
appear in the "Notes on Resources" section rather than "Notes on
Concurrent Operation". I'll move it up a subsection.

And with that, I will push it. Further changes are still possible and
suggestions are welcome, of course.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)