Horton

Thread

Commits

  1. Improve version reporting in pgbench.

  2. pgbench: Improve time logic.

  1. Version reporting in pgbench

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-18T17:20:21Z

    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

  2. Re: Version reporting in pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2021-06-18T18:27:16Z

    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.

  3. Re: Version reporting in pgbench

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-18T18:40:03Z

    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

  4. Re: Version reporting in pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2021-06-18T21:18:45Z

    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.

  5. Re: Version reporting in pgbench

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-18T21:28:39Z

    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

  6. Re: Version reporting in pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2021-06-18T21:37:44Z

    >> 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.