Note that if no connections are available, then you do not get the
version, which may be a little bit strange. Attached v3 prints out the
local version in that case. Not sure whether it is worth the effort.
I'm inclined to think that the purpose of that output is mostly
to report the server v
Fabien COELHO writes:
> Note that if no connections are available, then you do not get the
> version, which may be a little bit strange. Attached v3 prints out the
> local version in that case. Not sure whether it is worth the effort.
I'm inclined to think that the purpose of that output is mos
Hello Tom,
Why not move the printVersion call right after the connection is
created, at line 6374?
I started with that, and one of the 001_pgbench_with_server.pl
tests fell over --- it was expecting no stdout output before a
"Perhaps you need to do initialization" failure. If you don't
mind
Fabien COELHO writes:
> Why not move the printVersion call right after the connection is created,
> at line 6374?
I started with that, and one of the 001_pgbench_with_server.pl
tests fell over --- it was expecting no stdout output before a
"Perhaps you need to do initialization" failure. If you
Hello Tom,
One point here is that printing the server version requires
access to a connection, which printResults() hasn't got
because we already closed all the connections by that point.
I solved that by printing the banner during the initial
connection that gets the scale factor, does vacuum
I see that commit 547f04e73 caused pgbench to start printing its
version number. I think that's a good idea in general, but it
appears to me that next to no thought went into the details
(as perhaps evidenced by the fact that the commit message doesn't
even mention it). I've got two beefs with ho
