public inbox for [email protected]  

help / color / mirror / Atom feed

From: Amit Kapila <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Wed, 1 Apr 2026 17:51:40 +0530
Message-ID: <CAA4eK1LOsfpPqTV1+cN0qgXc3iKtDHS21Z0krDiSDu4hVqVG8g@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAA4eK1K=214d_Ya8jqMJQHamKxQXu8pxHux_cT0Ew0-AeE4K5Q@mail.gmail.com>
	<[email protected]>

On Wed, Apr 1, 2026 at 5:08 PM Alvaro Herrera <[email protected]> wrote:
>
> On 2026-Apr-01, Amit Kapila wrote:
>
> > What about if the blocking process is an autovacumm that is working to
> > prevent XID wraparound? I think we already avoid killing it in such
> > cases.
>
> If we just let REPACK finish, it will also renew the table's XID, so
> autovacuum is not needed in that case.  I mean, there's no reason to let
> autovacuum process the contents of a table that is going to be replaced
> completely.
>
> One potentially problematic case would be that an emergency autovacuum
> has been running for a long time and about to finish, and REPACK is
> started.  But in that case, autovacuum already has ShareUpdateExclusive,
> so REPACK wouldn't be able to start at all, which means it won't kill
> autovacuum.  And in the case where autovacuum is doing emergency
> vacuuming, then it won't commit suicide, so it will be able to complete
> before repack starts.
>
> > BTW, one can say that cancelling a long-running report query also
> > wastes a lot of effort of the user generating such a report. Why can't
> > REPACK wait for such a select to finish instead of cancelling it?
>
> I don't understand exactly which scenario you're concerned about.  Is
> there a long-running query which, after spending a lot of time running a
> report, tries to upgrade its lock level on the table?  Keep in mind that
> this check only runs when the affected session runs the deadlock
> checker, which means it's been waiting to acquire a lock for
> deadlock_timeout seconds.  It's not repack that kills the query.
>
> [ ... reflects ...]  Oh, actually what Srinath proposed does exactly
> that -- kill other queries.  Hmm, yeah, I'm less sure about that
> particular bit.
>

Yes, I was talking about Srinath's proposed solution. Do we need to do
anything about it?

-- 
With Regards,
Amit Kapila.

view thread (19+ messages)  latest in thread

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: <CAA4eK1LOsfpPqTV1+cN0qgXc3iKtDHS21Z0krDiSDu4hVqVG8g@mail.gmail.com>

* 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