Re: Lock problem with autovacuum truncating heap

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I like all of:

> 1) move the truncating to a new transaction just like we currently do
> toast tables in a separate transaction from the main vacuum.

+1 if we are going to continue the behavior of allowing other
transactions to kick autovac off the exclusive lock. However, if we can
find a way to avoid the need of that, then breaking it into multiple
transactions would just be useless complication (and extra cycles).

In particular, I thought the direction Jan was headed was to release and
reacquire the lock between truncating off limited-size chunks of the
file. If we do that, we probably *don't* want or need to allow autovac
to be booted off the lock more quickly.

> 2) Don't bother trying to truncate if we've been called from
> autovacuum at all.

No, I think that's seriously going in the wrong direction. We are
trying to make autovacuum more useful and transparent, not find new
reasons why people have to use manual vacuuming.

> 3) Scanning backwards 8MB at a time scanning each 8MB forwards instead
> of just going back by block backwards.

Maybe. I'd want to see some experimental evidence justifying the choice
of chunk size; I'm pretty sure this will become counterproductive once
the chunk size is too large.

regards, tom lane