On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> >> 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.
>
> I think that would be going too far: if an autovac wakes up in the dead of
> night, it should not use an ancient stats file merely because no one else
> has asked for stats recently. But if it never waits at all, it'll be
> at the mercy of whatever is already on disk.
Whoops; I underestimated the upper bound on time between stats file writes.
> After looking at the code, the minimum-change alternative would be more or
> less as attached: first, get rid of the long-obsolete proposition that
> autovacuum workers need fresher-than-usual stats; second, allow
> pgstat_vacuum_stat to accept stats that are moderately stale (the number
> given below allows them to be up to 50 seconds old); and third, suppress
> wait-timeout warnings when the call is from pgstat_vacuum_stat. The third
> point is what we need to avoid unnecessary buildfarm failures. The second
> point addresses the idea that we don't need to stress the stats collector
> too much for this.
Only #3 belongs in a minimum-change patch. #1 and #2 solve and/or create
different problems and operate independently of #3. A patch covering #3 alone
sounds attractive.