From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | John Lumby <johnlumby(at)hotmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: admin control over cancelling autovacuum when blocked by a lock |
Date: | 2019-04-30 01:37:44 |
Message-ID: | 19579.1556588264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> 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
>> Is there any configuration parameter which controls this?
>> including deferring or even completely eliminating this cancelling?
> 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.
I think the OP is looking for the opposite, ie prevent autovacuum from
being kicked off the lock. It already is resistant to that if we're
doing an anti-wraparound vacuum, so maybe the simplest answer is to
tighten up autovacuum_freeze_max_age. (Whether that's a good idea
is a different question.) Or you could just launch a manual vacuum.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-04-30 01:44:22 | Re: admin control over cancelling autovacuum when blocked by a lock |
Previous Message | John Lumby | 2019-04-30 01:14:52 | Re: admin control over cancelling autovacuum when blocked by a lock |