Re: admin control over cancelling autovacuum when blocked by a lock

Поиск
Список
Период
Сортировка
От John Lumby
Тема Re: admin control over cancelling autovacuum when blocked by a lock
Дата
Msg-id DM6PR06MB556232B024E3A05413B1B4D9A33A0@DM6PR06MB5562.namprd06.prod.outlook.com
обсуждение исходный текст
Ответ на Re: admin control over cancelling autovacuum when blocked by a lock  (Rui DeSousa <rui@crazybean.net>)
Ответы Re: admin control over cancelling autovacuum when blocked by a lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
On 04/30/2019 04:34 PM, Rui DeSousa wrote:
>
>
>> On Apr 30, 2019, at 4:04 PM, John Lumby <johnlumby@hotmail.com 
>> <mailto:johnlumby@hotmail.com>> wrote:
>>
>> surely the user would prefer that the
>> ANALYZE would wait until after
>> the autovacuum has finished
>
> 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.

Maybe it takes an exclusive lock on the catalog(?),   but (if it does) 
that should be brief at the very end
and not conflict with queries except rarely with the planner reading the 
catalog.

>
> I had the follow problem occur; which I hope will illustrate why you 
> wouldn’t what do what you are recommending.
>
> [ ... ]
> * The real response is we had to kill the session attempting to issue 
> analyze and issue a hot fix otherwise the blocking would cause all 
> sorts of application issues.
>
>
>


В списке pgsql-admin по дате отправления:

Предыдущее
От: Rui DeSousa
Дата:
Сообщение: Re: admin control over cancelling autovacuum when blocked by a lock
Следующее
От: Tom Lane
Дата:
Сообщение: Re: admin control over cancelling autovacuum when blocked by a lock