Version reporting in pgbench

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Version reporting in pgbench
Date: 2021-06-18 17:20:21
Message-ID: 1226654.1624036821@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
pgbench-version-banner-1.patch text/x-diff 1.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2021-06-18 17:27:57 A few nuances about specifying the timeline with START_REPLICATION
Previous Message John Naylor 2021-06-18 17:03:05 Re: PoC: Using Count-Min Sketch for join cardinality estimation