Conception of max-retry option seems strange for me. if number of retries
reaches max-retry option, then we just increment counter of failed
transaction and try again (possibly, with different random numbers). At the
end we should distinguish number of error transaction and failed transaction,
to found this difference documentation suggests to rerun pgbench with
debugging on.
May be I didn't catch an idea, but it seems to me max-tries should be
removed. On transaction searialization or deadlock error pgbench should
increment counter of failed transaction, resets conditional stack, variables,
etc but not a random generator and then start new transaction for the first
line of script.
ISTM that there is the idea is that the client application should give up
at some point are report an error to the end user, kind of a "timeout" on
trying, and that max-retry would implement this logic of giving up: the
transaction which was intented, represented by a given initial random
generator state, could not be committed as if after some iterations.
Maybe the max retry should rather be expressed in time rather than number
of attempts, or both approach could be implemented? But there is a logic
of retrying the same (try again what the client wanted) vs retrying
something different (another client need is served).
--
Fabien.
