Hi, Jeff Janes in [1] found that I ([2]) broke autovacuum cancellations. It obviously would be good to add a test for this, but it seems hard to have that be reliable given how long it can take for autovacuum actually get around to vacuum a specific table.
That made me wonder if it'd be worthwhile to add an option that'd make user invoked VACUUM be interruptible by conflicting lock requests, just like autovacuum is. That's actually something I've wanted, and see other people want, a couple times. Sometimes one wants to vacuum a table, but not block out more important things like DDL. Which isn't really possible right now. So how about adding an INTERRUPTIBLE option to VACUUM and ANALYZE? Implementation wise it seems like the best way to implement this would be to replace PROC_VACUUM_FOR_WRAPAROUND with PROC_INTERRUPTIBLE_VACANALYZE or such (i.e. inverting the meaning). One question I'm a bit split on is whether we'd want to continue restricting the signalling in ProcSleep() to commands running VACUUM or ANALYZE. We could have a generic PROC_INTERRUPTIBLE_COMMAND or such, and have deadlock.c / proc.c trigger whether to kill based on just that, without looking at PROC_IS_AUTOVACUUM / PROC_IN_VACUUM. Alternatively, if we do want to restrict it to VACUUM and ANALYZE, we'd have to re-introduce PROC_IN_ANALYZE ;). After 12 years of not being used and removed just weeks ago... Greetings, Andres Freund [1] https://postgr.es/m/20200827213506.4baaanygq62q7pcj%40alap3.anarazel.de [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d72f6c750
