Hello Fabien,
On Mon, 14 Jun 2021 11:30:14 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> >>> 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.
I agreed that when an initial connections fails we cannot start a bench
in the condition that the user wants and that we should stop early to let
the user know it and check the conf.
I attached a patch, which is a fusion of my previous patch that changes the
state to CSTATE_ABORT when the socket get failure during the bench, and a
part of your patch attached in [1] that exits for initial failures.
[1] https://www.postgresql.org/message-id/alpine.DEB.2.22.394.2106141011100.1338009%40pseudo
> 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?
> 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. I am working on rebase of the patch [2] and I will
submit this in a few days.
[2] https://www.postgresql.org/message-id/20210524112910.444fbfdfbff747bd3b9720ee@sraoss.co.jp
--
Yugo NAGATA <nagata@sraoss.co.jp>