Re: autovacuum truncate exclusive lock round two
От | Dimitri Fontaine |
---|---|
Тема | Re: autovacuum truncate exclusive lock round two |
Дата | |
Msg-id | m24nkq8pm4.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | autovacuum truncate exclusive lock round two (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: autovacuum truncate exclusive lock round two
|
Список | pgsql-hackers |
Jan Wieck <JanWieck@Yahoo.com> writes: > Use this lmgr feature inside count_nondeletable_pages() of vacuumlazy.c to > periodically check, if there is a conflicting lock request waiting. If not, > keep going. If there is a waiter, truncate the relation to the point checked > thus far, release the AccessExclusiveLock, then loop back to where we > acquire this lock in the first place and continue checking/truncating. I think that maybe we could just bail out after releasing the AccessExclusiveLock and trust autovacuum to get back to truncating that relation later. That would allow removing 2 of the 3 GUCs below: > autovacuum_truncate_lock_check = 100ms # how frequent to check > # for conflicting locks This is the one remaining. Could we maybe check for lock conflict after every move backward a page, or some multiple thereof? The goal would be to ensure that progress is made, while also being aware of concurrent activity, ala CHECK_FOR_INTERRUPTS(). Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: