From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <202603162202.l2sibdzviih7@alvherre.pgsql>
References: <202603162202.l2sibdzviih7@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
   message dated "Mon, 16 Mar 2026 23:03:04 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9547.1773744820.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Mar 2026 11:53:40 +0100
Message-ID: <9548.1773744820@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/9548.1773744820%40localhost>
Precedence: bulk

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

> On 2026-Mar-16, Matthias van de Meent wrote:
> =

> > On Mon, 16 Mar 2026 at 21:15, Antonin Houska <ah@cybertec.at> wrote:
> =

> > > Anyway (fortunately?), the concurrent use of slots by REPACK is limi=
ted
> > > because, during the initialization of logical decoding, the backend =
needs to
> > > wait for all the transactions having XID assigned to finish, and the=
se include
> > > the already running REPACK commands. See SnapBuildWaitSnapshot() and=
 callers
> > > if you're interested in details.
> > =

> > Huh, so would you be able to run more than one Repack Concurrently in
> > the same database? ISTM that would not be possible, apart from
> > possibly a mechanism comparable to the SAFE_IN_IC flag (to not wait on
> > those backends).
> =

> Yeah, this sounds kind of bad news ...

Admittedly, it is a problem. I tried to address this in pg_squeeze by
pre-allocating slots when it's clear (due to scheduling) that more than on=
e
table needs to be processed. This was an effort to achieve the best possib=
le
performance rather than a response to complaints of users about low
throughput. Nevertheless, I'm glad I happened to mention it before it's to=
o
late.

Regarding solution, a flag like SAFE_IN_IC alone does not help. The
information that particular transaction is used by REPACK (and therefore i=
t
does not have to be decoded) would need to be propagated to the
xl_running_xacts WAL record too.

The enhancements I wrote for PG 20 (not all of them posted yet) that aim a=
t
eliminating the impact of REPACK on VACUUM xmin horizon should fix this
problem: due to the MVCC-safety (i.e. preserving xmin/xmax of the tuples),
REPACK will not need XID assigned (except for catalog changes, which will
happen in separate transactions), so it won't block the logical decoding s=
etup
of other backends.

So the question is whether we should implement a workaround for PG 19, tha=
t
won't be needed in v20.

-- =

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