From: Antonin Houska <ah@cybertec.at>
To: Robert Treat <rob@xzilla.net>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
    Amit Kapila <amit.kapila16@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: 
 <CABV9wwMrrP4S54jPGn5D-a8AbJm+e5+WORs6ykUBgXdc-++NtQ@mail.gmail.com>
References: 
 <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
 <202604062213.cgo352cdsgsm@alvherre.pgsql>
 <CABV9wwMrrP4S54jPGn5D-a8AbJm+e5+WORs6ykUBgXdc-++NtQ@mail.gmail.com>
Comments: In-reply-to Robert Treat <rob@xzilla.net>
   message dated "Tue, 07 Apr 2026 15:43:50 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 08 Apr 2026 09:31:55 +0200
Message-ID: <6607.1775633515@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/6607.1775633515%40localhost>
Precedence: bulk

Robert Treat <rob@xzilla.net> wrote:

> On Mon, Apr 6, 2026 at 6:22=E2=80=AFPM Alvaro Herrera <alvherre@alvh.no-i=
p.org> wrote:
> > On 2026-Apr-06, Mihail Nikalayeu wrote:
> <snip>
> >
> > Anyway, here's the three missing parts.  I have not yet edited the
> > deadlock-checker one to protect autovacuum from processing tables under
> > repack.
> >
>=20
> I have this lingering bit of paranoia that users could end up in a
> situation with a large / long running repack that goes past failsafe
> age which prevents the simpler fix of failsafe autovacuum from
> running. While the repack finishing would resolve this issue, we can't
> know ahead of time that the repack would finish in time, and
> statistically speaking, failsafe autovacuum should generally run much
> quicker than any repack could. I'm not sure if that means we should
> let failsafe vacuum cancel repacks (that seems a bit extreme), but
> maybe we want to help $operator to think about this decision, except
> if we don't allow autovacuum to wait and we don't allow it to respawn,
> I wonder if the end user will ever realize they are in this position.
> Granted, there doesn't seem like a clean fix for this...

If REPACK is not going to finish in time, I think it makes little difference
whether VACUUM is allowed to wait or not: even if it waits, it will start j=
ust
too late. One reason to avoid waiting might be to allow autovacuum to work =
on
other tables in between.

I agree that the DBA should have some guidance to asses whether REPACK or
(failsafe) VACUUM is the appropriate action. While failsafe VACUUM is clear=
ly
a means to avoid XID wraparound, I tend to consider REPACK primarily a comm=
and
to remove table bloat. Or is there a situation where REPACK is better even =
to
avoid the wraparound?

Technically, the deadlock can be avoided by not running DDLs on the table
while REPACK is running. I'm just thinking if, by mentioning this in the
REPACK documentation, we'd admit that the REPACK (CONCURRENTLY) feature is
actually incomplete. On the other hand, if we don't mention the risk of
deadlock, it's a similar situation to not mentioning it for commands like
ALTER TABLE: if ALTER TABLE performs table rewrite, deadlock can also result
in a significant amount of wasted resources. (Of course, it's not the same =
if
the purpose of REPACK is considered substitute for failsafe VACUUM, but I'm
not sure about that.)

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