Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
От | Robert Haas |
---|---|
Тема | Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Дата | |
Msg-id | CA+Tgmobh1B6H=jZfHtxhPNNgL7rZw1qjQ9WXa4Kc8tT5PrmOCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
|
Список | pgsql-hackers |
On Mon, Jan 19, 2015 at 11:30 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2015-01-19 11:28:41 -0500, Tom Lane wrote: >> Andres Freund <andres@2ndquadrant.com> writes: >> > On 2015-01-19 11:16:09 -0500, Tom Lane wrote: >> >> 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". >> >> > Yes, that seems like a good message improvement. >> >> > It's not like making it LOG makes the message invisible... >> >> Uh, yes it does. So far as the user is concerned anyway. > > Sure, but the log isn't invisible. As mentioned one paragraph above, I > don't think it's likely to ever be noticed in the client code in the > cases where it happens in production. Yes, that is my feeling as well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: