Feedback-ID: id4a34324:Fastmail
Date: Sun, 12 Apr 2026 10:02:59 -0400
From: Andres Freund <andres@anarazel.de>
To: Robert Treat <rob@xzilla.net>
Cc: Antonin Houska <ah@cybertec.at>, 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]
Message-ID: <mblmhxohve7gmbhs7rp7wnuh5otcl3al6x4xdueuflmcwx3bi4@ucunrba2ldor>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAJSLCQ2R9uUfP-1kdCBvHYhU_iuKjVpCByViZQ+Qnwan4nDU3w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/mblmhxohve7gmbhs7rp7wnuh5otcl3al6x4xdueuflmcwx3bi4%40ucunrba2ldor>
Precedence: bulk

Hi,

On 2026-04-10 12:14:59 -0400, Robert Treat wrote:
> On Thu, Apr 9, 2026 at 10:20 AM Andres Freund <andres@anarazel.de> wrote:
> > > Anti-wraparound (failsafe) VACUUM is a bit different case [1] (i.e. it should
> > > possibly have higher priority than REPACK), but I think this prioritization
> > > should be implemented in other way than just letting it get in the way 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.
> >
> 
> 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 really understand why you consider REPACK CONCURRENTLY to be so
different from other existing long-running operations?


> 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

I don't think what I suggested could lead to (auto-)vacuum getting cancelled?
Antonin's earlier patch could, but as long as you only do cancellations if
there's an actual deadlock cycle, VACUUM should not get cancelled, since it
won't already hold a lower level lock?


> , 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.

Not sure I buy this (leaving aside the premise doesn't hold, I think). If you
have monitoring for either long running tasks or tables not getting
autovacuumed, it'd pick up on that regardless of whether autovacuum is getting
cancelled or not.  What realistic monitoring would pick up on autovacuum just
being stuck waiting for a lock for long, but would not pick up on repack
running forever or age(datfrozenxid) getting a bit long in the tooth?

Greetings,

Andres Freund