Re: autovacuum truncate exclusive lock round two

On 10/25/2012 12:24 PM, Alvaro Herrera wrote:
> Jan Wieck wrote:
>
>> In the original code, the maximum delay that autovacuum can cause by
>> holding the exclusive lock is one deadlock_timeout (default 1s). It
>> would appear reasonable to me to use max(deadlock_timeout/10,10ms)
>> as the interval to check for a conflicting lock request. For another
>> transaction that needs to access the table this is 10 times faster
>> than it is now and still guarantees that autovacuum will make some
>> progress with the truncate.
>
> So you would be calling GetCurrentTimestamp() continuously? Since you
> mentioned adding a vacuum delay point I wonder if it would make sense to
> test for lockers each time it would consider going to sleep, instead.
> (One hazard to keep in mind is the case where no vacuum delay is
> configured.)

Depends on your definition of "continuously". If doing one
INSTR_TIME_SET_CURRENT(), which on Unix boils down to a gettimeofday(),
every 32 ReadBufferExtended() calls counts as continuously, then yes.

Adding a vacuum_delay_point() is something we should consider. However,
the vacuum_delay_point() call simply naps when enough cost has been
racked up. You don't know if the next call will nap or not. We would
have to extend that functionality with some vacuum_delay_would_nap()
call to do what you suggest.

Jan

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