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.