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.
