Hello,
Indeed. I took your next patch with an added explanation. I'm unclear
whether proceeding makes much sense though, that is some thread would run
the test and other would have aborted. Hmmm.
Your comment looks good, thanks. In the previous version pgbench starts
benchmarking even if some connections fail. And users can notice the
connection failure by stderr output. Hence the current specification may
be enough.
Usually I run many pgbench through scripts, so I'm probably not there to
check a lone stderr failure at the beginning if performance figures are
actually reported.
If you agree, please remove the following lines:
```
+ * It is unclear whether it is worth doing
anything rather than
+ * coldly exiting with an error message.
```
I can remove the line, but I strongly believe that reporting performance
figures if some client connection failed thus the bench could not run as
prescribed is a bad behavior. The good news is that it is probably quite
unlikely. So I'd prefer to keep it and possibly submit a patch to change
the behavior.
ISTM that there is another patch in the queue which needs barriers to
delay some initialization so as to fix a corner case bug, in which case
the behavior would be mandatory. The current submission could add an
option to skip the barrier synchronization, but I'm not enthousiastic to
add an option and remove it shortly later.
Could you tell me which patch you mention? Basically I agree what you say,
but I want to check it.
Should be this one: https://commitfest.postgresql.org/30/2624/,
--
Fabien.
