On Thursday, April 11, 2013, Tom Lane wrote:
[ pokes around ... ] You certain 9.2.3 didn't do this too? This
appears to be an intentional behavior of the 9.2.3 patch that made it
cancel truncation when there were conflicting lock requests:
/*
* Report results to the stats collector, too. An early terminated
* lazy_truncate_heap attempt suppresses the message and also cancels the
* execution of ANALYZE, if that was ordered.
*/
if (!vacrelstats->lock_waiter_detected)
pgstat_report_vacuum(RelationGetRelid(onerel),
onerel->rd_rel->relisshared,
new_rel_tuples);
else
vacstmt->options &= ~VACOPT_ANALYZE;
However I've got to say that both of those side-effects of
exclusive-lock abandonment seem absolutely brain dead now that I see
them. Why would we not bother to tell the stats collector what we've
done? Why would we think we should not do ANALYZE when we were told to?
I believe the rationale was so that an autovacuum would still look like it was needed, and get fired again the next naptime, so that it could continue with the truncation attempts. (Rather than waiting for 20% turnover in the table before trying again). I'm not convinced by this argument. If the DBA is desperate to get the space back, they can go do vacuum full. Otherwise, let the space get nibbled away on the ordinary autovac schedule.
Cheers,
Jeff
