Re: Better way of dealing with pgstat wait timeout during buildfarm runs?

On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> To get back to that original complaint about buildfarm runs failing,
> I notice that essentially all of those failures are coming from "wait
> timeout" warnings reported by manual VACUUM commands. Now, VACUUM itself
> has no need to read the stats files. What's actually causing these
> messages is failure to get a timely response in pgstat_vacuum_stat().
> So let me propose a drastic solution: let's dike out this bit in vacuum.c:
>
> /*
> * Send info about dead objects to the statistics collector, unless we are
> * in autovacuum --- autovacuum.c does this for itself.
> */
> if ((vacstmt->options & VACOPT_VACUUM) && !IsAutoVacuumWorkerProcess())
> pgstat_vacuum_stat();
>
> This would have the effect of transferring all responsibility for
> dead-stats-entry cleanup to autovacuum. For ordinary users, I think
> that'd be just fine. It might be less fine though for people who
> disable autovacuum, if there still are any.

Like Robert, I don't care for that.

> Or, much more simply, we could conclude that it's not that important
> if pgstat_vacuum_stat() is unable to get up-to-date stats, and rejigger
> the code so that we don't bleat when the file-reading request comes from
> that source. This should be a back-patchable fix, whereas #2 above might
> be a bit too complicated for that.

This, however, feels like a clear improvement. When every VACUUM does
pgstat_vacuum_stat(), it doesn't matter if any given VACUUM misses removing
entries that became obsolete in the preceding second or so. In fact, rather
than merely not bleating when the wait times out, let's not wait at all. I
don't favor VACUUM of a small table taking 12s because it spent 2s on the
table and 10s waiting to garbage collect a piping-hot stats file.