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?
|
Список | 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 по дате отправления: