On Wed, Apr 1, 2026 at 5:08 PM Alvaro Herrera <alvherre@alvh.no-ip.org> 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.
