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.
