Re: autovacuum truncate exclusive lock round two

Jan,

* Jan Wieck (JanWieck(at)Yahoo(dot)com) wrote:
> This problem has been discussed before. Those familiar with the
> subject please skip the next paragraph.

Apologies if this was already thought-of and ruled out for some reason,
but...

> Because all the scanning had been done in parallel to normal DB
> activity, it needs to verify that all those blocks are still empty.

Would it be possible to use the FSM to figure out if things have changed
since the last scan..? Does that scan update the FSM, which would then
be updated by another backend in the event that it decided to write
something there? Or do we consider the FSM to be completely
untrustworthy wrt this (and if so, I don't suppose there's any hope to
using the visibility map...)?

The notion of having to double-scan and the AccessExclusiveLock on the
relation are telling me this work-around, while completely possible,
isn't exactly ideal...

Perhaps another option would be a page-level or something which is
larger than per-row (strikes me as a lot of overhead for this and it's
not clear how we'd do it), but less than an entire relation, but there
are certainly pain points there too.

Thanks,

Stephen