roachtest: cdc/poller/rangefeed=false failed #61176
Assignees
Labels
branch-master
Failures and bugs on the master branch.
C-test-failure
Broken test (automatically or manually discovered).
O-roachtest
O-robot
Originated from a bot.
release-blocker
Indicates a release-blocker. Use with branch-release-2x.x label to denote which branch is blocked.
Comments
cockroach-teamcity
added
branch-master
|
I see a panic: |
|
@miretskiy assigning to you as CDC L2. |
|
(roachtest).cdc/poller/rangefeed=false failed on master@6de4313ec216161c79fe725fcc31fc87ef1804ea: More
Artifacts: /cdc/poller/rangefeed=false See this test on roachdash |
|
Looks like panic occurs in kv land in rangefeed. @nvanbenschoten or @ajwerner have you seen this before? |
|
|
@tbg @andreimatei Can you confirm if this is KV? Also, need to confirm if this is a release blocker. |
|
Confirmed on both |
|
In |
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
Mar 8, 2021
Before this patch, the resolved timestamp computation code didn't handle closed timestamps with logical parts properly. I believe we didn't use to have such closed timestamps under "the old" closed timestamp mechanism, and we also don't have with the "new one" [*]. Still, the resolved timestamp should support them. The trouble was when the resolved timestamp was tracking an intent at, say, 11.0, with the closed timestamp at 10.2. resolvedTimestamp.recompute() was doing FloorPrev(11)==10, and compared that with the closed ts. It was freaking out when the FloorPrev was going below the closed timestamp. This patch rewords this logic to handle this case. [*] Before cockroachdb#61559, the new closed ts code did sometimes close logical timestamps - when we were trying to close above the lease expiration, we were doing Backwards(leaseExpiration) (and leases with a logical expiration are possible, although that seems separately dubious to me). This case change in cockroachdb#61559, which added physical rounding to the respective lease expiration. Fixes cockroachdb#61176 - although I think the bug has gone back to hidden after cockroachdb#61559 Release note: None Release justification: Sort of bug fix for new functionality. But more importantly, this affords extra flexibility to 21.1 in dealing with potential changes in 21.2.
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
Mar 9, 2021
Before this patch, the resolved timestamp computation code didn't handle closed timestamps with logical parts properly. I believe we didn't use to have such closed timestamps under "the old" closed timestamp mechanism, and we also don't have with the "new one" [*]. Still, the resolved timestamp should support them. The trouble was when the resolved timestamp was tracking an intent at, say, 11.0, with the closed timestamp at 10.2. resolvedTimestamp.recompute() was doing FloorPrev(11)==10, and compared that with the closed ts. It was freaking out when the FloorPrev was going below the closed timestamp. This patch rewords this logic to handle this case. [*] Before cockroachdb#61559, the new closed ts code did sometimes close logical timestamps - when we were trying to close above the lease expiration, we were doing Backwards(leaseExpiration) (and leases with a logical expiration are possible, although that seems separately dubious to me). This case change in cockroachdb#61559, which added physical rounding to the respective lease expiration. Fixes cockroachdb#61176 - although I think the bug has gone back to hidden after cockroachdb#61559 Release note: None Release justification: Sort of bug fix for new functionality. But more importantly, this affords extra flexibility to 21.1 in dealing with potential changes in 21.2.
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
Mar 11, 2021
Before this patch, the resolved timestamp computation code didn't handle closed timestamps with logical parts properly. I believe we didn't use to have such closed timestamps under "the old" closed timestamp mechanism, and we also don't have with the "new one" [*]. Still, the resolved timestamp should support them. The trouble was when the resolved timestamp was tracking an intent at, say, 11.0, with the closed timestamp at 10.2. resolvedTimestamp.recompute() was doing FloorPrev(11)==10, and compared that with the closed ts. It was freaking out when the FloorPrev was going below the closed timestamp. This patch rewords this logic to handle this case; we now truncate the resolved timestamp to a physical timestamp. [*] Before cockroachdb#61559, the new closed ts code did sometimes close logical timestamps - when we were trying to close above the lease expiration, we were doing Backwards(leaseExpiration) (and leases with a logical expiration are possible, although that seems separately dubious to me). This case change in cockroachdb#61559, which added physical rounding to the respective lease expiration. Fixes cockroachdb#61176 - although I think the bug has gone back to hidden after cockroachdb#61559 Release note: None Release justification: Sort of bug fix for new functionality. But more importantly, this affords extra flexibility to 21.1 in dealing with potential changes in 21.2.
andreimatei
added a commit
to andreimatei/cockroach
that referenced
this issue
Mar 11, 2021
Before this patch, the resolved timestamp computation code didn't handle closed timestamps with logical parts properly. I believe we didn't use to have such closed timestamps under "the old" closed timestamp mechanism, and we also don't have with the "new one" [*]. Still, the resolved timestamp should support them. The trouble was when the resolved timestamp was tracking an intent at, say, 11.0, with the closed timestamp at 10.2. resolvedTimestamp.recompute() was doing FloorPrev(11)==10, and compared that with the closed ts. It was freaking out when the FloorPrev was going below the closed timestamp. This patch rewords this logic to handle this case; we now truncate the resolved timestamp to a physical timestamp. [*] Before cockroachdb#61559, the new closed ts code did sometimes close logical timestamps - when we were trying to close above the lease expiration, we were doing Backwards(leaseExpiration) (and leases with a logical expiration are possible, although that seems separately dubious to me). This case change in cockroachdb#61559, which added physical rounding to the respective lease expiration. Fixes cockroachdb#61176 - although I think the bug has gone back to hidden after cockroachdb#61559 Release note: None Release justification: Sort of bug fix for new functionality. But more importantly, this affords extra flexibility to 21.1 in dealing with potential changes in 21.2.
craig bot
pushed a commit
that referenced
this issue
Mar 11, 2021
60946: changefeedccl: Envelope schema name reflects schema config r=[stevendanna] a=HonoreDB Fixes a bug where the Avro -envelope schema name, as opposed to subject, did not honor the schema prefix and full table name options. Release note (bug fix): Envelope schema in avro registry now honors schema_prefix and full_table_name 61662: rangefeed: handle closed timestamps with logical parts r=andreimatei a=andreimatei Before this patch, the resolved timestamp computation code didn't handle closed timestamps with logical parts properly. I believe we didn't use to have such closed timestamps under "the old" closed timestamp mechanism, and we also don't have with the "new one" [*]. Still, the resolved timestamp should support them. The trouble was when the resolved timestamp was tracking an intent at, say, 11.0, with the closed timestamp at 10.2. resolvedTimestamp.recompute() was doing FloorPrev(11)==10, and compared that with the closed ts. It was freaking out when the FloorPrev was going below the closed timestamp. This patch rewords this logic to handle this case. [*] Before #61559, the new closed ts code did sometimes close logical timestamps - when we were trying to close above the lease expiration, we were doing Backwards(leaseExpiration) (and leases with a logical expiration are possible, although that seems separately dubious to me). This case change in #61559, which added physical rounding to the respective lease expiration. Fixes #61176 - although I think the bug has gone back to hidden after #61559 Release note: None Release justification: Sort of bug fix for new functionality. But more importantly, this affords extra flexibility to 21.1 in dealing with potential changes in 21.2. 61790: colexec: propagate disk full error as expected r=yuzefovich a=yuzefovich Previously, we would always propagate the errors emitted by the spilling queues and disk queues as "internal" which resulted in errors being annotated. However, "disk full" errors are expected to occur, so this commit cleans that up. Additionally, it plumbs the propagation into the spilling queue's `Enqueue` method itself to remove some of the duplicated code. Fixes: #61769. Release note: None Co-authored-by: Aaron Zinger <zinger@cockroachlabs.com> Co-authored-by: Andrei Matei <andrei@cockroachlabs.com> Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(roachtest).cdc/poller/rangefeed=false failed on master@6601d827b814d4e85a1081b03bf2562d8ac2a4ab:
More
Artifacts: /cdc/poller/rangefeed=false
See this test on roachdash
powered by pkg/cmd/internal/issues
The text was updated successfully, but these errors were encountered: