workload/tpcc: optionally disable txn retry loops#117096
workload/tpcc: optionally disable txn retry loops#117096craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
Informs cockroachdb#115191. This commit adds a `--txn-retries` flag to `tpcc`, allowing users of the workload to disable transaction retry loops for 40001 errors. For Serializable transactions (controllable with `--isolation-level`), this quickly leads to errors being thrown by the workload. For Read Committed transaction, the workload eventually hits an error due to a lease transfer. Combined with a prototype fix for cockroachdb#61986, Read Committed transactions survive for at least a few minutes without error. Release note: None
michae2
left a comment
There was a problem hiding this comment.
Good idea. Should we add a roachtest that tries to run TPC-C under RC without retries as long as possible without an error?
Read Committed transactions survive for at least a few minutes without error.
Hmm. A few minutes is better, of course, but it seems like applications will probably still need to use client-side retries for 23.2? I left a few comments to this effect on cockroachdb/docs#18098 (review)
Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @arulajmani, @nvanbenschoten, @renatolabs, and @srosenberg)
pkg/workload/tpcc/tpcc.go line 910 at r1 (raw file):
txOpts := pgx.TxOptions{} if w.txnRetries { return crdbpgx.ExecuteTx(ctx, conn, txOpts, fn)
@rafiss: Do you think we should add a variant of crdbpgx.ExecuteTx that doesn't use client-side retries? Or some kind of configuration helper? I guess there is a crdb.WithMaxRetries, but it assumes 0 to mean "infinite retries".
|
TFTR! bors r=michae2
Yes, I think that's a good idea. I mentioned it in #115191.
Sorry, to clarify:
I looked into It's also worth pointing out that when retries are omitted, we can avoid the |
|
Build succeeded! And happy new year! 🎉 |
Closes cockroachdb#115191. Depends on cockroachdb#61986. This commit switches the two nightly Read Committed variants of the TPC-C roachtest to run without transaction retry loops, using the `--txn-retries` flag introduced in cockroachdb#117096. With cockroachdb#117630 and cockroachdb#61986 resolved (the latter of which is still in review and under development), these tests both pass. Release note: None
Closes cockroachdb#115191. Depends on cockroachdb#61986. This commit switches the two nightly Read Committed variants of the TPC-C roachtest to run without transaction retry loops, using the `--txn-retries` flag introduced in cockroachdb#117096. With cockroachdb#117630 and cockroachdb#61986 resolved (the latter of which is still in review and under development), these tests both pass. Release note: None
118000: roachtest: run Read Committed variants of TPC-C without txn retry loops r=nvanbenschoten a=nvanbenschoten Closes #115191. Depends on #61986. This commit switches the two nightly Read Committed variants of the TPC-C roachtest to run without transaction retry loops, using the `--txn-retries` flag introduced in #117096. With #117630 and #61986 resolved (the latter of which is still in review and under development), these tests both pass. Release note: None 118600: gceworker bootstrap: fix checksum for go download r=rickystewart a=jlinder On the last go version upgrade to cockroach, the wrong checksum was entered in the gceworker bootstrap script for the downloaded tar file. This fixes it to be the correct checksum. Epic: none Release note: None Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com> Co-authored-by: James H. Linder <jamesl@cockroachlabs.com>
Informs #115191.
This commit adds a
--txn-retriesflag totpcc, allowing users of the workload to disable transaction retry loops for 40001 errors.For Serializable transactions (controllable with
--isolation-level), this quickly leads to errors being thrown by the workload. For Read Committed transaction, the workload eventually hits an error due to a lease transfer. Combined with a prototype fix for #61986, Read Committed transactions survive for at least a few minutes without error.Release note: None