> #5 0x0000000000402b2b in doConnect () at pgbench.c:650
> #6 0x0000000000404591 in doCustom (thread=0x25c2f40, st=0x25c2770,
> conn_time=0x25c2f90, logfile=0x0, agg=0x7fffba224260) at pgbench.c:1353
> #7 0x000000000040a1d5 in threadRun (arg=0x25c2f40) at pgbench.c:3581
> #8 0x0000000000409ab4 in main (argc=12, argv=0x7fffba224668) at pgbench.c:3455
Hmm. Ok, whatever the connection position (from doCustom or from
threadRun), doConnect would block the thread. On the other hand, if you
start several threads, probably those threads which could connect all
their client would proceed.
What looks to be needed would be some timeout when connecting to the
server.
>> The formula change, and just this one, should probably be backported
>> somehow, as this is a bug, wherever pgbench resides in older
>> versions. It is just 's/nthreads/nclients/' in the printResult formula
>> for computing tps_exclude.
>
> Yeah, that's definitely a bug but I'm afraid the fix will change the
> TPS number and may break the backward compatibility. Since we have
> lived with bug for years, I hesitate to back port to older stable
> branches...
My 2¥: I do not think of a good argument to keep wrong tps numbers once it
is known that there are plain wrong, especially as it is not a behavioral
change as such which could block applications or whatever, just a
different number printed at the end of a run. So I would not bother much
with upward compatibility consideration in this case.
--
Fabien.
