From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Amit Kapila <amit.kapila16@gmail.com>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <202604011042.zdevjay65ws7@alvherre.pgsql>
References: <202604011042.zdevjay65ws7@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Wed, 01 Apr 2026 13:42:17 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <198172.1775049644.1@localhost>
Date: Wed, 01 Apr 2026 15:20:44 +0200
Message-ID: <198173.1775049644@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/198173.1775049644%40localhost>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> So, if we're unable to get this particular patch in, we would have to
> have a big fat warning in the docs, telling people to be careful about
> other load if they choose to run concurrent repack -- it could have
> serious consequences.  But on the other hand, it's better to *have* the
> tool, even if it has problems, than not have it.  Keep in mind that
> pg_repack and pg_squeeze also have all these problems/limitations (and
> others), and still people use them.

1. To be precise, pg_squeeze has this limitation. pg_repack does not use
logical replication.

2. I expect the limitation of PG core to be relaxed in versions > 19, as long
as we integrate the MVCC safety feature. REPACK will then run w/o XID most of
the time (XID will only be needed for catalog changes), so other decoding
backends won't need to wait for its completion.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com