Feedback-ID: ia2694551:Fastmail
Date: Fri, 31 Oct 2025 00:17:05 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Antonin Houska <ah@cybertec.at>,
	Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <202510301734.pj4uds3mqxx4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ecl2euvoqutt27wj"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202507262156.sb455angijk6@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/202510301734.pj4uds3mqxx4%40alvherre.pgsql>
Precedence: bulk


--ecl2euvoqutt27wj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

Here's a new installment of this series, v25, including the CONCURRENTLY
part, which required some conflict fixes on top of the much-changed
v24-0001 patch.

After the talk on this subject for PGConf.EU, there were some
reservations about this whole project, and if I understand correctly,
they can be summarized in these three points:

1. Would the spill files for reorderbuffers occupy as much disk space as
it takes to copy the initial contents of the table, for each active
logical decoding replication slot?  Antonin claims (I haven't verified
this) that there are some hacks in place to avoid this problem, or that
it is easy to install some -- and if so, then this patch would already
be better than pg_repack.  This perhaps merits more testing.

2. Is the concurrent REPACK operation MVCC-safe?  At the moment, with
the present implementation, no it is not.  There are discussions on
getting this fixed, and Mihail has proposed some patches which at least
are quite short, though their safety is something we need to assess in
more depth.

3. Would the xmin horizon remain stuck at the spot where REPACK started,
thereby preventing VACUUM from cleaning up recently-dead rows in other
tables?  As I understand, with the current implementation, yes it would,
and we cannot easily apply hacks such as PROC_IN_VACUUM to prevent it,
because it would introduce the same problems it did for CREATE INDEX
CONCURRENTLY that was fixed in pg14 (commit 042b584c7f7d62).  Mihail and
Antonin have discussed possible ways to ease this, but we don't have
code for that yet.  This is, again, no worse than VACUUM FULL or
CLUSTER, so lack of this wouldn't be a killer for this project, though
of course it would be much better to do better.


I have not yet addressed Robert Treat's feedback from October 12th.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")

--ecl2euvoqutt27wj
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
	filename="v25-0001-Add-REPACK-command.patch"
Content-Transfer-Encoding: 8bit