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
