Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
От | Alvaro Herrera |
---|---|
Тема | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Дата | |
Msg-id | 20141226034926.GB1645@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
|
Список | pgsql-hackers |
Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > So I think a better way to deal with that warning would be a good > > idea. Besides somehow making the mechanism there are two ways to attack > > this that I can think of, neither of them awe inspiring: > > > 1) Make that WARNING a LOG message instead. Since those don't get send > > to the client with default settings... > > 2) Increase PGSTAT_MAX_WAIT_TIME even further than what 99b545 increased > > it to. > > Yeah, I've been getting more annoyed by that too lately. I keep wondering > though whether there's an actual bug underneath that behavior that we're > failing to see. I think the first thing to do is reconsider usage of PGSTAT_RETRY_DELAY instead of PGSTAT_STAT_INTERVAL in autovacuum workers. That decreases the wait time 50-fold, if I recall this correctly, and causes large amounts of extra I/O traffic. > BTW, I notice that in the current state of pgstat.c, all the logic for > keeping track of request arrival times is dead code, because nothing is > actually looking at DBWriteRequest.request_time. This makes me think that > somebody simplified away some logic we maybe should have kept. I will have a look. I remember being confused about this at some point when reviewing that patch. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: