Hello Tom,
Remove pgbench "progress" test pending solution of its timing issues.
It would have been nicer to simply comment them out...
Buildfarm member skink shows that this is even more flaky than I thought. There are probably some actual pgbench bugs here as well as a timing dependency.
According to the trace, the host was so loaded that it could not do anything for over two seconds, so that the first output is "progress: 2.6", i.e. the 0 thread did not get any significant time for the first 2.6 seconds... of a 1 second test. Hmmm, not very kind.
Somehow this cannot be helped: if the system does not give any execution time to some pgbench thread, the expected output cannot be there.
The checked condition could be relaxed to "progress: \d", which still assumes that the system was kind enough to give enough cpu time to the process in the two second run so that it could output something.
The issue is probably the same on the second test on the generated log. My guess is that some transactions (we are talking about "-S"...) took several seconds, thus were completed and aggregate in rows over the expected limit. Could be considered bug, that is the aggregation should discard over the limit results rather than counting them in some late entry. I'll investigate that.
Globally these test failures reveals pathological testing conditions: the inability to execute a simple select over several seconds. It could have been OOM or whatever else.
If the test must run even when postgres doesn't, it is a little bit hard as a starting assumption for a benchmarking tool:-(
-- Fabien. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
