-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
roachtest: scaledata/filesystem_simulator/nodes=3 failed #43273
Comments
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-19.2@7e9d38c44864898657bcd095b21cebe4702fa2da:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-2.1@a32057733127620847d5121d54984f4b5be9f33a:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-19.1@a85a9a4ee0440cccdfd3e314b8f01394e52bdf3f:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@dd9b1c1f40dda59ee9d446416106d311ae5ce1e6:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-19.2@599c988773fa6fb4544369a50fe8d06b90c64171:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-19.2@9aaf5fb6f7108858d200dd3d199deb11871a09b4:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@0046d62b00aa9e74489d1f44125948c9af729e2b:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@3c408a47707a15d4b5c92031c4eafcfa643d307c:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@e671a4ef97cbc6cf5d22f8f322fd45733d302094:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@bb14400cdd1397f47c3781b4830199f169cef497:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@36273d3daa0bb659b58e826c67e6079f0747aac6:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@b797cad6d130714748983bc53d4611ddc6151153:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@fc5c7f093bf1e86852c3b839bc0f6710d9902729:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@3e2334ded18d2f18c08f2f912be085df563ca6ff:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@5f9a71adb995837bcff27b9456188018434be4b8:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@d6a52a8f6f07b3b6b32af2243075e5365fb21c45:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@954fe69d554162aec0fbc001aad1fe5103d8df13:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on master@c473f40078994551cebcbe00fdbf1fa388957658:
More
Artifacts: /scaledata/filesystem_simulator/nodes=3
See this test on roachdash |
Also, @irfansharif do you know whether https://github.com/scaledata/rksql/pull/6 was included when you re-deployed these tests? |
It wasn't. It's currently deployed at https://github.com/irfansharif/rksql/tree/aaa85833508aad281d9defe8b0edd63bc6103faa. I'll include that before tonight's runs. |
This is exactly what we're running into. What do we want the new write timestamp to be? Should it not stay at 3 (given that it got to 3 for a good reason)? |
We were informed to bump up our read and write timestamps, but we already have a higher write timestamp, so we should simply be pulling up our read timestamp to match. Option 2 makes sense to me too. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I just added this to the 20.1 release blocker list. |
Picked it up on this new fork: https://github.com/cockroachdb/rksql |
After cockroachdb#46004, locking scans can now hit WriteTooOld errors if they encounter values at timestamps higher than their read timestamps. The `ActualTimestamp` recorded is the `encountered ts + 1`. When determining what the new timestamp for the txn should be, previously we blindly used the generated `encountered ts + 1`. This was buggy, and could lead to a timestamp regression in the case where a txn with (read_ts, write_ts) = (1, 4) finds a value with `ts = 2`. If we try to "bump" the txn to `ts = 3`, we're regressing the write ts. Now, when determining what the new timestamp should be, we ensure we use `max(encountered ts + 1, txn's current write ts)`. Fixes cockroachdb#43273. Release note: None Release justification: High-priority bug fix (resulted in panics for contended UPDATEs)
I'm not able to repro the panic with #46750. |
After cockroachdb#46004, locking scans can now hit WriteTooOld errors if they encounter values at timestamps higher than their read timestamps. The `ActualTimestamp` recorded is the `encountered ts + 1`. When determining what the new timestamp for the txn should be, previously we blindly used the generated `encountered ts + 1`. This was buggy, and could lead to a timestamp regression in the case where a txn with (read_ts, write_ts) = (1, 4) finds a value with `ts = 2`. If we try to "bump" the txn to `ts = 3`, we're regressing the write ts. Now, when determining what the new timestamp should be, we ensure we use `max(encountered ts + 1, txn's current write ts)`. Fixes cockroachdb#43273. Release note: None Release justification: High-priority bug fix (resulted in panics for contended UPDATEs)
This comment has been minimized.
This comment has been minimized.
Same issue as #43273 (comment), which is fixed by #46750. |
46750: kvserver: disallow timestamp regression with locking scans r=irfansharif a=irfansharif After #46004, locking scans can now hit WriteTooOld errors if they encounter values at timestamps higher than their read timestamps. The `ActualTimestamp` recorded is the `encountered ts + 1`. When determining what the new timestamp for the txn should be, previously we blindly used the generated `encountered ts + 1`. This was buggy, and could lead to a timestamp regression in the case where a txn with (read_ts, write_ts) = (1, 4) finds a value with `ts = 2`. If we try to "bump" the txn to `ts = 3`, we're regressing the write ts. Now, when determining what the new timestamp should be, we ensure we use `max(encountered ts + 1, txn's current write ts)`. Fixes #43273. Release note: None 46762: RBAC SQL diagram updates r=richardjcai a=Amruta-Ranade RBAC SQL diagram updates Release note: None Release justification: Docs change Co-authored-by: irfan sharif <[email protected]> Co-authored-by: Amruta <[email protected]>
This might still flake on retry errors that are not captured as retry errors, but those are innocuous, and now that we have https://github.com/cockroachdb/rksql, can fix them on the fly. |
After cockroachdb#46004, locking scans can now hit WriteTooOld errors if they encounter values at timestamps higher than their read timestamps. The `ActualTimestamp` recorded is the `encountered ts + 1`. When determining what the new timestamp for the txn should be, previously we blindly used the generated `encountered ts + 1`. This was buggy, and could lead to a timestamp regression in the case where a txn with (read_ts, write_ts) = (1, 4) finds a value with `ts = 2`. If we try to "bump" the txn to `ts = 3`, we're regressing the write ts. Now, when determining what the new timestamp should be, we ensure we use `max(encountered ts + 1, txn's current write ts)`. Fixes cockroachdb#43273. Release note: None Release justification: High-priority bug fix (resulted in panics for contended UPDATEs)
46858: release-20.1: kvserver: disallow timestamp regression with locking scans r=irfansharif a=irfansharif Backport 1/1 commits from #46750. /cc @cockroachdb/release --- After #46004, locking scans can now hit WriteTooOld errors if they encounter values at timestamps higher than their read timestamps. The `ActualTimestamp` recorded is the `encountered ts + 1`. When determining what the new timestamp for the txn should be, previously we blindly used the generated `encountered ts + 1`. This was buggy, and could lead to a timestamp regression in the case where a txn with (read_ts, write_ts) = (1, 4) finds a value with `ts = 2`. If we try to "bump" the txn to `ts = 3`, we're regressing the write ts. Now, when determining what the new timestamp should be, we ensure we use `max(encountered ts + 1, txn's current write ts)`. Fixes #43273. Release note: None Co-authored-by: irfan sharif <[email protected]>
(roachtest).scaledata/filesystem_simulator/nodes=3 failed on release-19.1@f8a99239043416cf032b47fd3ce71e4e364a0af1:
Repro
Artifacts: /scaledata/filesystem_simulator/nodes=3
powered by pkg/cmd/internal/issues
The text was updated successfully, but these errors were encountered: