Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
От | Tom Lane |
---|---|
Тема | Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Дата | |
Msg-id | 27251.1421684169@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: Better way of dealing with pgstat wait timeout
during buildfarm runs?
Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Sure, but nobody who is not a developer is going to care about that. > A typical user who sees "pgstat wait timeout", or doesn't, isn't going > to be able to make anything at all out of that. Possibly we need to improve the wording of that error message then. When it was written, we really assumed that it was a can't-happen case and so didn't spend much effort on it. Perhaps it should become a translatable ereport phrased like "WARNING: using stale statistics instead of current ones because stats collector is not responding". (I'm also wondering if it'd make sense to expose the stats timestamp as a callable function, so that the case could be dealt with programmatically as well. But that's future-feature territory.) >> 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. > But I can live with this compromise. Is that OK with everybody? Going once, going twice ... regards, tom lane
В списке pgsql-hackers по дате отправления: