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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 19, 2015 at 7:09 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2015-01-18 21:33:25 -0500, Robert Haas wrote:
>>> 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).

If that were true I'd agree with you, but it's false on its face.
A user who is actually examining the statistics might well want to
know if they're significantly out of date. A very relevant example
is that I've always wondered how come, when we see buildfarm failures
in the "stats" regression test, they always appear in the form of
output differences that indicate that the session did not see the
expected stats update --- but there's never a timeout warning printed,
which indicates that whatever the cause is, it ain't that.

I'd be fine with changing the warning to LOG level rather than
suppressing it entirely for the specific case of pgstat_vacuum_stat;
but I do want to distinguish that case, wherein it's fair to conclude
that obsolete stats aren't too worrisome, from other cases where no
such conclusion is justified.

regards, tom lane