Horton

Re: pgbench bug candidate: negative "initial connection time"

Fabien COELHO <coelho@cri.ensmp.fr>

View thread View on postgr.es
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, "'pgsql-hackers@lists.postgresql.org'" <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-16T18:25:31Z
Lists: pgsql-hackers 
Hello Yugo-san,

>> When connection break while the bench has already started,
>> maybe it makes more sense to proceed,
>
> The result would be incomplete also in this case. However, the reason why
> it is worth to proceed is that  such information is still useful for users,
> or we don't want to waste the bench that has already started?

Hmmm. It depends on what the user is testing. If one is interested in 
client resilience under errors, the bench should probably attempt a 
reconnect. If one is interested in best performance when all is well,
then clearly something is amiss and there is no point to go on.

>> although I guess that maybe reattempting connections would make also 
>> sense in such case.
>
> This might become possible after pgbench gets the feature to retry in deadlock
> or serialization errors.

Yes, I agree that part of the needed infrastructure would be in place for 
that. As reconnecting is already in place under -c, so possibly it is just 
a matter of switching between states with some care.

> I am working on rebase of the patch [2] and I will submit this in a few 
> days.

Ok. Very good, I look forward to your submission! I'll be sure to look at 
it.

-- 
Fabien.

Commits

  1. pgbench: Fix typo in comment.

  2. pgbench: Improve error-handling in pgbench.

  3. pgbench: Fix handling of socket errors during benchmark.

  4. pgbench: Correct log level of message output when socket wait method fails.

  5. pgbench: Synchronize client threads.

  6. pgbench: Use common logging API