Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors

>> > I would tend to agree with this behavior, that is not to start any new
>> > transaction or transaction attempt once -T has expired.
>
> That is the behavior in the latest patch. Once -T has expired, any new
> transaction or retry does not start.

Actually v14 has not changed the behavior in this regard as explained
in different email:

> $ pgbench -p 11000 -c 10 -T 10 --max-tries=0 test
> pgbench (15devel, server 13.3)
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 1
> query mode: simple
> number of clients: 10
> number of threads: 1
> duration: 10 s
> number of transactions actually processed: 974
> number of failed transactions: 9 (0.916%)
> number of transactions retried: 651 (66.226%)
> total number of retries: 8482
> latency average = 101.317 ms (including failures)
> initial connection time = 44.440 ms
> tps = 97.796487 (without initial connection time)

>> > I'm a little hesitant about how to count and report such unfinished
>> > because of bench timeout transactions, though. Not counting them seems
>> > to be the best option.
>>
>> I agree.
>
> I also agree. Although I couldn't get an answer what does he think the actual
> harm for users due to termination of retrying by the -T option is, I guess it just
> complained about reporting the termination of retrying as failures. Therefore,
> I will fix to finish the benchmark when the time is over during retrying, that is,
> change the state to CSTATE_FINISHED instead of CSTATE_ERROR in such cases.

I guess Fabien wanted it differently. Suppose "-c 10 and -T 30" and we
have 100 success transactions by time 25. At time 25 pgbench starts
next benchmark cycle and by time 30 there are 10 failing transactions
(because they are retrying). pgbench stops the execution at time
30. According your proposal (change the state to CSTATE_FINISHED
instead of CSTATE_ERROR) the total number of success transactions will
be 100 + 10 = 110, right? I guess Fabien wants to have the number to
be 100 rather than 110.

Fabien,
Please correct me if you think differently.

Also actually I have explained the harm number of times but you have
kept on ignoring it because "it's subtle". My request has been pretty
simple.

> number of failed transactions: 9 (0.916%)

I don't like this and want to have the failed transactions to be 0.
Who wants a benchmark result having errors?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp