>>> Hmmm. Possibly. Another option could be not to report anything after some
>>> errors. I'm not sure, because it would depend on the use case. I guess the
>>> command returned an error status as well.
>>
>> I did not know any use cases and decisions , but I vote to report nothing when error occurs.
>
> I would prefer to abort the thread whose connection got an error and report
> results for other threads, as handled when doConnect fails in CSTATE_START_TX
> state.
It is unclear to me whether it makes much sense to report performance when
things go wrong. At least when a one connection per client bench is run
ISTM that it should not proceed, because the bench could not even start
as prescribe. When connection break while the bench has already started,
maybe it makes more sense to proceed, although I guess that maybe
reattempting connections would make also sense in such case.
> In this case, we have to set the state to CSTATE_ABORT before going to 'done'
> as fixed in the attached patch, in order to ensure that exit status is 2 and the
> result reports "pgbench: fatal: Run was aborted; the above results are incomplete."
Hmmm. I agree that at least reporting that there was an issue is a good
idea.
> Otherwise, if we want pgbench to exit immediately when a connection error occurs,
> we have tocall exit(1) to ensure the exit code is 1, of course. Anyway, it is wrong
> that thecurrent pgbench exit successfully with exit code 0 when doConnnect fails.
Indeed, I can only agree on this one.
--
Fabien.
