Re: pgbench bug candidate: negative "initial connection time"

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench bug candidate: negative "initial connection time"
Date: 2021-06-14 08:07:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, 14 Jun 2021 00:42:12 +0000
"kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:

> Dear Fabien,
> Thank you for replying!
> > 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

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."

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.

Yugo Nagata

Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
pgbench_connect_abort.patch text/x-diff 971 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-14 08:48:34 Re: Failure in subscription test
Previous Message Yugo NAGATA 2021-06-14 08:05:18 Re: pgbench bug candidate: negative "initial connection time"