]> granicus.if.org Git - postgresql/commit
Avoid hard-wired sleep delays in stats regression test.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 May 2017 13:42:12 +0000 (09:42 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 May 2017 13:42:12 +0000 (09:42 -0400)
commit4e37b3e15c4e129dbbcf46e00ad36672f4f7b359
tree8dfce24316af2c55234fd2e5c72e47f7feaf7e6e
parent8d9f06097714ce1f4243329172f73c2d20b896a6
Avoid hard-wired sleep delays in stats regression test.

On faster machines, the overall runtime for running the core regression
tests is under twenty seconds these days, of which the hard-wired delays
in the stats test are a significant fraction.  But on closer inspection,
it seems like we shouldn't need those.

The initial 2-second delay is there only to reduce the risk of the test's
stats messages not getting sent due to contention.  But analysis of the
last ten years' worth of buildfarm runs shows no evidence that such
failures actually occur.  (We do see failures that look like stats
messages not getting sent, particularly on Windows; but there is little
reason to believe that the initial delay reduces their frequency.)

The later 1-second delay is there to ensure that our session's stats
will have gotten sent.  But we could also do that by starting a fresh
session, which takes well under 1 second even on very slow machines.

Hence, let's remove both delays and see what happens.  The first delay
was the only test of pg_sleep_for() in the regression tests, but we can
move that responsibility into wait_for_stats().

Discussion: https://postgr.es/m/17795.1493869423@sss.pgh.pa.us
src/test/regress/expected/stats.out
src/test/regress/sql/stats.sql