From: Antonin Houska <ah@cybertec.at>
To: Robert Treat <rob@xzilla.net>
cc: Andres Freund <andres@anarazel.de>,
    Amit Kapila <amit.kapila16@gmail.com>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Srinath Reddy Sadipiralla <srinath2133@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: 
 <CAJSLCQ2R9uUfP-1kdCBvHYhU_iuKjVpCByViZQ+Qnwan4nDU3w@mail.gmail.com>
References: 
 <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
 <202604062213.cgo352cdsgsm@alvherre.pgsql>
 <4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2>
 <CAA4eK1JDrk9xiALd4DHnGLOkGDbObM59SXSBJyj0_1bNYbr5ng@mail.gmail.com>
 <gebmxzovxumuflknpua4r52tmuiam2odies2qlchzcl36cvphc@iz6bkpk64amp>
 <CADzfLwUed3gmARGbHnsDbrXsqPRW0b0VUtZxi5iNJj0LTC2fJA@mail.gmail.com>
 <CAA4eK1JDd9HBOtR5pgAptcQHpUyXROMe5jqBbLGBRBqn+rCYCg@mail.gmail.com>
 <9539.1775724194@localhost>
 <fpr4nsmyy3mpfrm2mijspr44dgol2cjeke5tyznb4btsznxsgx@iifdbfe2wl63>
 <CAJSLCQ2R9uUfP-1kdCBvHYhU_iuKjVpCByViZQ+Qnwan4nDU3w@mail.gmail.com>
Comments: In-reply-to Robert Treat <rob@xzilla.net>
   message dated "Fri, 10 Apr 2026 12:14:59 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Apr 2026 20:56:42 +0200
Message-ID: <138051.1775847402@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/138051.1775847402%40localhost>
Precedence: bulk

Robert Treat <rob@xzilla.net> wrote:

> On Thu, Apr 9, 2026 at 10:20=E2=80=AFAM Andres Freund <andres@anarazel.de=
> wrote:
> > On 2026-04-09 10:43:14 +0200, Antonin Houska wrote:
> > > Anti-wraparound (failsafe) VACUUM is a bit different case [1] (i.e. i=
t should
> > > possibly have higher priority than REPACK), but I think this prioriti=
zation
> > > should be implemented in other way than just letting it get in the wa=
y of
> > > REPACK (at the time REPACK is nearly finished).
> >
> > Yea, it makes no sense to interrupt the long running repack, given that=
 the
> > new relation will have much less stuff for vacuum to do.
> >
>=20
> We might be talking about 2 different scenarios. In the case where we
> are at the point of lock escalation, you would probably want the
> repack to get priority over a waiting vacuum, even a failsafe vacuum.
> But outside of that scenario, we can't know that the repack is the
> better option (and statistically it probably isn't) since a repack
> that is actively copying rows might still need to rebuild some large
> number of indexes (or just some really expensive index) which could
> take significantly longer than a failsafe vacuum would need to ensure
> wraparound avoidance. I don't think we'd go as far as saying the
> failsafe vacuum should cancel the repack, but I think ideally we'd
> like it to not be canceled either, since that would increase
> likelihood for dba/monitoring to pick up on the situation, and in the
> case that REPACK fails for some reason, the failsafe vacuum could
> immediately start working without having to go through any additional
> hoops.

What about just teaching the anti-wraparound VACUUM to print out a WARNING =
if
it could not lock the table in "reasonable" time? The DBA would then have to
consider if the blocking command should be cancelled, whether it's REPACK or
something else.

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