Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables

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