| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | John Lumby <johnlumby(at)hotmail(dot)com> |
| Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: admin control over cancelling autovacuum when blocked by a lock |
| Date: | 2019-04-29 23:15:08 |
| Message-ID: | CANP8+jJSysBHF_QRdYmT-iKQDy4yw8OaqgiLoNJPdjTX1bJB8w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Mon, 29 Apr 2019 at 22:02, John Lumby <johnlumby(at)hotmail(dot)com> wrote:
> If a regular backend worker becomes blocked waiting for a lock held by an
> autovacuum worker,
> then , depending on some decision made by deadlock detector,
> the autovacuum worker may be signalled to terminate
>
> This results in messages such as these in the statement log
>
>
> ERROR: canceling autovacuum task
> CONTEXT: automatic vacuum of table "somedb.aschema.thistable"
>
> Is there any configuration parameter which controls this?
> including deferring or even completely eliminating this cancelling?
> so that, in the eliminate case, the waiter would simply go on waiting
> until the autovacuum eventually finishes "thistable"?
>
> I have not seen any parameter to do this.
> Note that I don't mean some parameter which affects all locking behaviour,
> only this autovacuum case.
>
Why would you want this?
If the autovacuum is cancelled, it will re-execute again in the near
future, once your interrupting SQL has released locks.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Lumby | 2019-04-30 01:14:52 | Re: admin control over cancelling autovacuum when blocked by a lock |
| Previous Message | John Lumby | 2019-04-29 21:02:40 | admin control over cancelling autovacuum when blocked by a lock |