-
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
*,isql: introduce isql.Txn and isql.DB #93218
Conversation
3eb1ba1
to
3bff2bb
Compare
LGTM. I reviewed this PR looking at the changes in my editor and came up with some very uncontroversial fixes which I'm publishing as a patch file below. In addition to that, my comments:
|
4511145
to
4bc6970
Compare
bors r+ |
Build failed:
|
The flake was #92809. I keep trying to repro with bors r+ |
9936310
to
00c2509
Compare
Canceled. |
This massive refactor works to bind the `*kv.Txn` with the internal executor and other sql-layer, txn-associated state. This work follows on from an earlier project to more tightly couple internal executors to the rest of `extraTxnState`. That project resulted in sprawling changes to propagated the paired dependencies through the system. In practice, we're better off coupling them through an object. There are some refactors added in here to curry and hide some of these dependencies from interfaces. Those may be possible to extract to be separate. Additionally, not all of the dependency sprawl has been eliminated; there are cases where we could pass a `isql.Txn` but instead keep passing the underlying `isql.Executor` and `*kv.Txn`. We can do more cleanup along the way. Lastly, I couldn't help myself from lifting some `sql.ExecCfg` arguments up and being more specific in some places. Epic: none Release note: None
00c2509
to
2f81142
Compare
bors r+ 🤞 |
Build failed (retrying...): |
Build succeeded: |
It seems like this change made it much more likely for the race in #92809 to occur, and I have a fix in flight. Andrew, you could have just pinged me to fix it sooner if it was bothering you :) |
@yuzefovich I stressed it with |
I think the failure occurs when the node is quescing at the end of the logic test, and perhaps |
This commit is to use the new internal executor interface introduced by cockroachdb#93218 for `schemachanger.txn()`. informs cockroachdb#91004 Release Note: None
95963: kvserver: use narrow checkpoints in consistency checker r=tbg,erikgrinaker a=pavelkalinnikov This commit modifies the consistency checker to save partial checkpoints instead of full ones. The partial checkpoints contain the data for the inconsistent range and its immediate left and right neighbour in the Store. Only the inconsistent range's Replica is locked at the time of snapshotting the store before creating the checkpoint, other ranges can be out of sync. They are checkpointed too, to give more context when e.g. debugging non-trivial split/merge scenarios. Release note (ops change): In the rare event of Range inconsistency, the consistency checker saves a storage checkpoint on each storage the Range belongs to. Previously, this was a full checkpoint, so its cost could quickly escalate on the nodes that went on running. This change makes the checkpoints partial, i.e. they now only contain the relevant range and its neighbours. This eliminates the time pressure on the cluster operator to remove the checkpoints. Resolves #90543 Epic: none 96243: schemachanger: Implement `ADD CONSTRAINT NOT VALID` r=Xiang-Gu a=Xiang-Gu This PR implements the following three statements in the declarative schema changer: - `ALTER TABLE ... ADD CHECK ... NOT VALID` - `ALTER TABLE ... ADD UNIQUE WITHOUT INDEX ... NOT VALID` - `ALTER TABLE ... ADD FOREIGN KEY ... NOT VALID` The idea is to introduce a new element for each statement. That element is like simple dependent and will transition between ABSENT and PUBLIC directly. Epic: None 96598: sql: use `descs.Txn` for `schemachanger.txn` r=ajwerner a=ZhouXing19 This commit includes just mechanical changes to use the new internal executor interface introduced by #93218 for `schemachanger.txn()`. informs #91004 Release Note: None Co-authored-by: Pavel Kalinnikov <[email protected]> Co-authored-by: Xiang Gu <[email protected]> Co-authored-by: Jane Xing <[email protected]>
The KVDB field was created as part of PR cockroachdb#93218, but it was never initialized. Part of cockroachdb#94843 Release Note: None
98268: kvcoord: Close done context if init fails r=miretskiy a=miretskiy When we close mux rangefeed init context due to an error, it is important to also close client done context so that this error can be propagated to the caller. Epic: None Release note: None 98489: upgradejob: initialize the kvdb on TenantDeps r=JeffSwenson a=JeffSwenson The KVDB field was created as part of PR #93218, but it was never initialized. Part of #94843 Release Note: None Co-authored-by: Yevgeniy Miretskiy <[email protected]> Co-authored-by: Jeff <[email protected]>
This massive refactor works to bind the
*kv.Txn
with the internal executor and other sql-layer, txn-associated state. This work follows on from an earlier project to more tightly couple internal executors to the rest ofextraTxnState
. That project resulted in sprawling changes to propagated the paired dependencies through the system. In practice, we're better off coupling them through an object.There are some refactors added in here to curry and hide some of these dependencies from interfaces. Those may be possible to extract to be separate.
Additionally, not all of the dependency sprawl has been eliminated; there are cases where we could pass a
isql.Txn
but instead keep passing the underlyingisql.Executor
and*kv.Txn
. We can do more cleanup along the way.Lastly, I couldn't help myself from lifting some
sql.ExecCfg
arguments up and being more specific in some places.Epic: none
Release note: None