Re: admin control over cancelling autovacuum when blocked by a lock
От
Tom Lane
Тема
Re: admin control over cancelling autovacuum when blocked by a lock
Дата
Msg-id
25357.1556658210@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
admin control over cancelling autovacuum when blocked by a lock John Lumby <johnlumby@hotmail.com>
Re: admin control over cancelling autovacuum when blocked by a lock Simon Riggs <simon@2ndquadrant.com>
Re: admin control over cancelling autovacuum when blocked by a lock Tom Lane <tgl@sss.pgh.pa.us>
Re: admin control over cancelling autovacuum when blocked by a lock John Lumby <johnlumby@hotmail.com>
Re: admin control over cancelling autovacuum when blocked by a lock Tom Lane <tgl@sss.pgh.pa.us>
Re: admin control over cancelling autovacuum when blocked by a lock Simon Riggs <simon@2ndquadrant.com>
Re: admin control over cancelling autovacuum when blocked by a lock John Lumby <johnlumby@hotmail.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 MichaelDBA <MichaelDBA@sqlexec.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 John Lumby <johnlumby@hotmail.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 John Lumby <johnlumby@hotmail.com>
Re: admin control over cancelling autovacuum when blocked by a lock Tom Lane <tgl@sss.pgh.pa.us>
Re: admin control over cancelling autovacuum when blocked by a lock Rui DeSousa <rui@crazybean.net>
John Lumby 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 по дате отправления
От: John Lumby
Дата:
От: Rui DeSousa
Дата: