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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: WITH CHECK and Column-Level Privileges