-
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: cdc/tpcc-1000 failed #32813
Comments
Huh, it passes |
We got a `AS OF SYSTEM TIME: cannot specify timestamp in the future` error. I can't imagine how this would have happened besides the clocks being out of sync, so just subtract a second. Closes cockroachdb#32813 Release note: None
SHA: https://github.com/cockroachdb/cockroach/commits/ea4c00f5d7c33ece947a080cf56e63a33826565b Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1064508&tab=buildLog
|
Latest failure is an apt-get issue. |
SHA: https://github.com/cockroachdb/cockroach/commits/98ef7abf32784b8e837d18d10173ef083010ad45 Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1067238&tab=buildLog
|
Note that this |
The timestamp for the initial scan was previously generated on the test runner, which is usually someone's laptop or a teamcity machine. Avoid this by using the time interval AS OF SYSTEM TIME notation. This is a better fix for cockroachdb#32813 Release note: None
33363: roachtest: deflake cdc/initial-scan r=mrtracy a=danhhz The timestamp for the initial scan was previously generated on the test runner, which is usually someone's laptop or a teamcity machine. Avoid this by using the time interval AS OF SYSTEM TIME notation. This is a better fix for #32813 Release note: None Co-authored-by: Daniel Harrison <daniel.harrison@gmail.com>
SHA: https://github.com/cockroachdb/cockroach/commits/5cb2c3803d0ea3342415ab1a72ed86d356510e0b Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1086777&tab=buildLog
|
SHA: https://github.com/cockroachdb/cockroach/commits/d0e2f78183d2ce0a6b803127ee80143571c9cd4f Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1086794&tab=buildLog
|
SHA: https://github.com/cockroachdb/cockroach/commits/fe6fbbb99f51f414804daaeb704635ee0ff17b28 Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1091924&tab=buildLog
|
SHA: https://github.com/cockroachdb/cockroach/commits/772c8001911d14119cd78078c0c1acbc15c59142 Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1107318&tab=buildLog
|
this last one looks like it failed during test setup |
SHA: https://github.com/cockroachdb/cockroach/commits/8cbeb534432b81c57564956ed7d645b854b426be Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1111300&tab=buildLog
|
SHA: https://github.com/cockroachdb/cockroach/commits/e10fb557b11b5ff1b8609aa963da23c37a1143c8 Parameters: To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1113854&tab=buildLog
|
Interesting that all of the |
@nvanbenschoten Huh, that is interesting. I wonder if there's any interesting 30s constants. Closed timestamps? I don't see anything in the roachtest Note that these failures were run with rangefeed off, the test name was changed when I did that flip |
That's an interesting idea. I don't immediately see how that could be related, but I'll keep it in mind. Another very strange thing I'm seeing: these Another interesting note is that the |
Fixes cockroachdb#34025. Fixes cockroachdb#33624. Fixes cockroachdb#33335. Fixes cockroachdb#33151. Fixes cockroachdb#33149. Fixes cockroachdb#34159. Fixes cockroachdb#34293. Fixes cockroachdb#32813. Fixes cockroachdb#30886. Fixes cockroachdb#34228. Fixes cockroachdb#34321. It is rare but possible for a replica to become a leaseholder but not learn about this until it applies a snapshot. Immediately upon the snapshot application's `ReplicaState` update, the replica will begin operating as a standard leaseholder. Before this change, leases acquired in this way would not trigger in-memory side-effects to be performed. This could result in a regression in the new leaseholder's timestamp cache compared to the previous leaseholder, allowing write-skew like we saw in cockroachdb#34025. This could presumably result in other anomalies as well, because all of the steps in `leasePostApply` were skipped. This PR fixes this bug by detecting lease updates when applying snapshots and making sure to react correctly to them. It also likely fixes the referenced issue. The new test demonstrated that without this fix, the serializable violation speculated about in the issue was possible. Release note (bug fix): Fix bug where lease transfers passed through Snapshots could forget to update in-memory state on the new leaseholder, allowing write-skew between read-modify-write operations.
34548: storage: apply lease change side-effects on snapshot recipients r=nvanbenschoten a=nvanbenschoten Fixes #34025. Fixes #33624. Fixes #33335. Fixes #33151. Fixes #33149. Fixes #34159. Fixes #34293. Fixes #32813. Fixes #30886. Fixes #34228. Fixes #34321. It is rare but possible for a replica to become a leaseholder but not learn about this until it applies a snapshot. Immediately upon the snapshot application's `ReplicaState` update, the replica will begin operating as a standard leaseholder. Before this change, leases acquired in this way would not trigger in-memory side-effects to be performed. This could result in a regression in the new leaseholder's timestamp cache compared to the previous leaseholder's cache, allowing write-skew like we saw in #34025. This could presumably result in other anomalies as well, because all of the steps in `leasePostApply` were skipped (as theorized by #34025 (comment)). This PR fixes this bug by detecting lease updates when applying snapshots and making sure to react correctly to them. It also likely fixes the referenced issue. The new test demonstrates that without this fix, the serializable violation speculated about in the issue was possible. Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
SHA: https://github.com/cockroachdb/cockroach/commits/e6cb0c5c329617b560eee37527248171b5e06382
Parameters:
To repro, try:
Failed test: https://teamcity.cockroachdb.com/viewLog.html?buildId=1038478&tab=buildLog
The text was updated successfully, but these errors were encountered: