Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CABV9wwMrrP4S54jPGn5D-a8AbJm+e5+WORs6ykUBgXdc-++NtQ@mail.gmail.com
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
On Mon, Apr 6, 2026 at 6:22 PM Alvaro Herrera <alvherre@alvh.no-ip.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.
>

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

Robert Treat
https://xzilla.net



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats
Next
From: Heikki Linnakangas
Date:
Subject: Re: Better shared data structure management and resizable shared data structures