Re: admin control over cancelling autovacuum when blocked by a lock - Mailing list pgsql-admin

From Tom Lane
Subject Re: admin control over cancelling autovacuum when blocked by a lock
Date
Msg-id 25357.1556658210@sss.pgh.pa.us
Whole thread Raw
In response to Re: admin control over cancelling autovacuum when blocked by a lock  (John Lumby <johnlumby@hotmail.com>)
Responses Re: admin control over cancelling autovacuum when blocked by a lock
List pgsql-admin
John Lumby <johnlumby@hotmail.com> writes:
> On 04/30/2019 04:34 PM, Rui DeSousa wrote:
>> Not really… analyze takes an exclusive lock; I believe.  The result is 
>> that readers/analyze will block other readers and writes which is bad 
>> for concurrency.  Readers should never be blocked :)…

> Apparently not  -   at least,  not on the table being analyzed  : from 
> the 11.2 Reference :
> |ANALYZE| requires only a read lock on the target table, so it can run 
> in parallel with other activity on the table.

That's kind of inaccurate.  A moment's experimentation will show you
that what it really takes is ShareUpdateExclusiveLock, which it does
mostly to ensure that no other ANALYZE is running concurrently on the
same table.  That lock type doesn't block ordinary reads or writes
on the table.  It probably conflicts with autovacuum though ...

            regards, tom lane



pgsql-admin by date:

Previous
From: John Lumby
Date:
Subject: Re: admin control over cancelling autovacuum when blocked by a lock
Next
From: Rui DeSousa
Date:
Subject: Re: admin control over cancelling autovacuum when blocked by a lock