Re: Better way of dealing with pgstat wait timeout during buildfarm runs? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
Date
Msg-id 20141226034926.GB1645@alvh.no-ip.org
Whole thread Raw
In response to Re: Better way of dealing with pgstat wait timeout during buildfarm runs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better way of dealing with pgstat wait timeout during buildfarm runs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Some other odd buildfarm failures
Next
From: Noah Misch
Date:
Subject: Re: group locking: incomplete patch, just for discussion