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+TgmoZoocPjiWLi2LsAYhSO1VpH86b3x8AUcvOmRCVzrxHveg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reducing buildfarm disk usage: remove temp installs when done
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL