On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote: > Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers