#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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to