Re: (auto)vacuum truncate exclusive lock

Kevin Grittner <kgrittn@ymail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.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