Re: lazy vacuum sleeps with exclusive lock on table

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.

Are you sure that that is, and always will be, the only sleep in that
part of the code path?

Seems like it might be better to adjust the cost_delay parameters after
we acquire exclusive lock. I'm not sure dialing them all the way back
to zero is a good idea, but certainly we could make them more
aggressive.

>> Seems like VACUUM shouldn't try just once to get the lock.

> We don't know how many pages we can truncate until after we have
> acquired the exclusive lock and examined the pages in question, scanning
> backwards from the end of the table.

We could estimate this during the forward scan. The backward scan is
still necessary to see if anyone has inserted tuples after we looked at
a page, but certainly a page that VACUUM failed to empty will still be
nonempty, so we can determine an upper bound on how much might be
truncatable.

However, that's an orthogonal concern and should probably be discussed
separately.

regards, tom lane