#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
