Re: autovacuum truncate exclusive lock round two

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <JanWieck@Yahoo.com>
To: Kevin Grittner <kgrittn@mail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila@huawei.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2012-12-02T15:13:18Z
Lists: pgsql-hackers

Attachments

Attached is a new patch that addresses most of the points raised in 
discussion before.

1) Most of the configuration variables are derived from deadlock_timeout 
now. The "check for conflicting lock request" interval is 
deadlock_timeout/10, clamped to 10ms. The "try to acquire exclusive 
lock" interval is deadlock_timeout/20, also clamped to 10ms. The only 
GUC variable remaining is autovacuum_truncate_lock_try=2000ms with a 
range from 0 (just try once) to 20000ms.

I'd like to point out that this is a significant change in functionality 
as without the config option for the check interval, there is no longer 
any possibility to disable the call to LockHasWaiters() and return to 
the original (deadlock code kills autovacuum) behavior.

2) The partition lock in LockHasWaiters() was lowered to LW_SHARED. The 
LW_EXCLUSIVE was indeed a copy/paste result.

3) The instr_time handling was simplified as suggested.

4) Lower case TRUE/FALSE.


I did not touch the part about suppressing the stats and the ANALYZE 
step of "auto vacuum+analyze". The situation is no different today. When 
the deadlock code kills autovacuum, stats aren't updated either. And 
this patch is meant to cause autovacuum to finish the truncate in a few 
minutes or hours, so that the situation fixes itself.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin