On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>> On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > 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.
>>
>> I think this is too much of a good thing. I don't see any reason why
>> autovacuum's statistics need to be fresher than normal, but I also
>> don't see any reason why they need to be less fresh. I think
>> suppressing the warning is a good idea, but why only suppress it for
>> autovacuum? How about just knocking the level down to, say, DEBUG1?
>
> +1 for just using LOG - which by default does not end up on client
> machines. In contrast to WARNING.
Yeah, that doesn't seem like a bad idea, either. The message seems
much more likely to be of interest to the DBA than the user; the DBA
can use the message to diagnose an overloaded I/O subsystem (which I
think is the usual cause of this problem) whereas the only point of
likely interest to the user is that their query ran slowly (which they
know without the message).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company