public inbox for [email protected]
help / color / mirror / Atom feedFrom: Antonin Houska <[email protected]>
To: Robert Treat <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Wed, 08 Apr 2026 09:31:55 +0200
Message-ID: <6607.1775633515@localhost> (raw)
In-Reply-To: <CABV9wwMrrP4S54jPGn5D-a8AbJm+e5+WORs6ykUBgXdc-++NtQ@mail.gmail.com>
References: <CADzfLwWFr9h_+cbSQvPpdxgLbVL5wwxFRx21ezNvLYgJM=FVCQ@mail.gmail.com>
<[email protected]>
<CABV9wwMrrP4S54jPGn5D-a8AbJm+e5+WORs6ykUBgXdc-++NtQ@mail.gmail.com>
Robert Treat <[email protected]> wrote:
> On Mon, Apr 6, 2026 at 6:22 PM Alvaro Herrera <[email protected]> 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.
> >
>
> 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 just
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 clearly
a means to avoid XID wraparound, I tend to consider REPACK primarily a command
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.)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <6607.1775633515@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox