Re: [HACKERS] pgbench regression test failure

>>> 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