Date: Tue, 4 Jul 2017 19:23:04 -0700
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: Reducing runtime of stats regression test
Message-ID: <20170705022304.GA2132910@rfd.leadboat.com>
References: <17795.1493869423@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17795.1493869423@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Wed, May 03, 2017 at 11:43:43PM -0400, Tom Lane wrote:
> On a reasonably fast development machine, one of the biggest time sinks
> while running the core regression tests is the long "sleep" calls in the
> stats.sql regression test.  I took a closer look at these, and I think
> we could basically get rid of them.
> 
> First up is this bit at the beginning of that test script:
> 
> -- wait to let any prior tests finish dumping out stats;
> -- else our messages might get lost due to contention
> SELECT pg_sleep_for('2 seconds');
> 
> The stated concern isn't really all that plausible, since even if we
> launch a batch of test scripts at once, they don't all finish at once,
> so there's unlikely to be a big pileup of traffic to the stats collector.
> But we don't have to take that on faith: in assert-enabled builds,
> pgstat_send() logs any failure to send a stats message.
> 
> I have grepped the buildfarm logs for "could not send to statistics
> collector" log messages during the "make check" stage (a total of 754313
> runs dating back ten years).  What I find is that members mereswine and
> gull occasionally report "Network is down", and a few times currawong and
> thrips have complained "Invalid argument", and there are exactly no other
> such messages.  In particular there are no EAGAIN or EWOULDBLOCK failures
> that would suggest congestion on the stats collector's input.  So this
> is basically not something that happens at all in the regression tests,
> let alone during startup of the stats test in particular.

Linux and AIX, at least, do not make send() return an error when dropping a
UDP message for lack of queue space.  Thus, the lack of buildfarm logs
reporting send() failure is inconclusive.  Nonetheless, the lack of stats.sql
failures since you finished modifying this test in mid-May suggests this was a
good change.  Besides, if a new member were slow enough to experience a stats
pileup, I wouldn't have firm hope that 2s would suffice.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers