Re: (auto)vacuum truncate exclusive lock

Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think that the minimum appropriate fix here is to revert the hunk
>> I quoted, ie take out the suppression of stats reporting and analysis.

> I'm not sure I understand -- are you proposing that is all we do
> for both the VACUUM command and autovacuum?

No, I said that was the minimum fix.

Looking again at the patch, I note this comment:

/*
+ * We failed to establish the lock in the specified number of
+ * retries. This means we give up truncating. Suppress the
+ * ANALYZE step. Doing an ANALYZE at this point will reset the
+ * dead_tuple_count in the stats collector, so we will not get
+ * called by the autovacuum launcher again to do the truncate.
+ */

and I suppose the rationale for suppressing the stats report was this
same idea of lying to the stats collector in order to encourage a new
vacuum attempt to happen right away. Now I'm not sure that that's a
good idea at all --- what's the reasoning for thinking the table will be
any less hot in thirty seconds? But if it is reasonable, we need a
redesign of the reporting messages, not just a hack to not tell the
stats collector what we did.

Are you saying you intend to revert that whole concept? That'd be
okay with me, I think. Otherwise we need some thought about how to
inform the stats collector what's really happening.

regards, tom lane