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. Here I'm only talking about my proposal to have the
deadlock detector handle the case of somebody waiting to lock the table.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
