Apparently, one of the threads ran 3 transactions where the test script
expects it to run at most 2. Is this a pgbench bug, or is the test
being overoptimistic about how exact the "-T 2" cutoff is?
Probably both? It seems that cutting off on time is not a precise science,
so I suggest to accept 1, 2 and 3 lines, see attached.
Before I'd deciphered the test output fully, I was actually guessing that
the problem was the opposite, namely too few lines.
The test was waiting for betwen 1 and 2 lines, so I assumed that the 3
should the number of lines found.
Isn't it possible that some thread is slow enough to start up that it
doesn't get to run any transactions? IOW, do we need to allow 0 to 3
lines?
By definition, parallelism induces non determinism. When I put 2 seconds,
the intention was that I would get a non empty trace with a "every second"
aggregation. I would rather take a longer test rather than allowing an
empty file: the point is to check that something is generated, but
avoiding a longer test is desirable. So I would suggest to stick to
between 1 and 3, and if it fails then maybe add one second...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
