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