Version reporting in pgbench
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 how it was done:
* The output only mentions pgbench's own version, which would be
highly misleading if the server being used is of a different
version. I should think that in most cases the server's version
is more important than pgbench's.
* We have a convention for how client programs should print their
versions, and this ain't it. (Specifically, you should print the
PG_VERSION string not make up your own.)
What I think should have been done instead is to steal psql's
battle-tested logic for printing its startup version banner,
more or less as attached.
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 vacuuming, etc.
If you're dead set on not printing the version till the end,
that could be made to happen; but it's not clear to me that
this way is any worse, and it's certainly easier.
Thoughts?
regards, tom lane
Attachments:
pgbench-version-banner-1.patchtext/x-diff; charset=us-ascii; name=pgbench-version-banner-1.patchDownload+35-1
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 vacuuming, etc.
Ok.
If you're dead set on not printing the version till the end,
that could be made to happen; but it's not clear to me that
this way is any worse, and it's certainly easier.
pgbench (14beta1 dev 2021-06-12 08:10:44, server 13.3 (Ubuntu 13.3-1.pgdg20.04+1))
Why not move the printVersion call right after the connection is created,
at line 6374?
Otherwise it works for me.
--
Fabien.
Fabien COELHO <coelho@cri.ensmp.fr> 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 don't
mind changing that, I agree that printing immediately after
the connection is made is a bit less astonishing.
regards, tom lane
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 changing that,
Why would I mind?
I agree that printing immediately after the connection is made is a bit
less astonishing.
Ok, so let's just update the test? Attached a proposal with the version
moved.
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.
--
Fabien.
Fabien COELHO <coelho@cri.ensmp.fr> 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 mostly
to report the server version, so not printing it if we fail to
connect isn't very surprising. Certainly that's how psql has
acted for decades.
regards, tom lane
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 version, so not printing it if we fail to
connect isn't very surprising. Certainly that's how psql has
acted for decades.
I'm fine with having a uniform behavior over pg commands.
Thanks for the improvement!
--
Fabien.