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.
