Re: First steps with 8.3 and autovacuum launcher
От | Alvaro Herrera |
---|---|
Тема | Re: First steps with 8.3 and autovacuum launcher |
Дата | |
Msg-id | 20071003164230.GJ10624@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: First steps with 8.3 and autovacuum launcher (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: First steps with 8.3 and autovacuum launcher
|
Список | pgsql-hackers |
Alvaro Herrera escribió: > I think this is doable. We would need to add a phase 0 to ALTER TABLE > processing, which grabs a less strong (than AccessExclusive) lock on the > table, then goes over the list of commands and determine if at least one > of them requires exclusive access to the table (I think the criteria > here is whether table rewriting is needed, in which case AccessExclusive > is enough). If none of them does, then we press on. As expected, this idea didn't fly very far. The first problem I find is that DefineIndex grabs a new lock by itself; if it's not a concurrent build, it grabs ShareLock which immediately locks out ANALYZE. It is worse than it sounds at first, because as soon as we are starting ALTER TABLE with a less strong lock, then this ShareLock is deemed a lock upgrade, with the ensuing dangers for deadlocks. I'm starting to find this area of lock strength reduction a minefield, one on which it is very easy to step on a mine. So I'm back to considering a solution along the lines of cancelling a running autovacuum job. But I think I would do it only for ANALYZE, not vacuum. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4" "La espina, desde que nace, ya pincha" (Proverbio africano)
В списке pgsql-hackers по дате отправления: