| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: VACUUM (INTERRUPTIBLE)? |
| Date: | 2020-09-08 20:36:00 |
| Message-ID: | 20200908203600.GA9179@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-Sep-08, Andres Freund wrote:
> 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.
Yeah, I recall a request for this in the past, too.
> So how about adding an INTERRUPTIBLE option to VACUUM and ANALYZE?
+1 on adding it to VACUUM. I'm not sure about ANALYZE ... most of the
time it is not as bad as VACUUM in terms of blocking other things, and
things get ugly if that ANALYZE is part of a transaction. I think I'd
leave that out, since we don't have to cover all DDL that could take
ShareUpdateExclusive lock (CIC etc). VACUUM is especially problematic,
ISTM, which is we would do it for that.
> 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...
Hah :-)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2020-09-08 20:37:06 | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |
| Previous Message | Magnus Hagander | 2020-09-08 20:30:40 | Re: VACUUM (INTERRUPTIBLE)? |