adapter: use occ for read-then write, with incremental retries#35192
Draft
aljoscha wants to merge 11 commits intoMaterializeInc:mainfrom
Draft
adapter: use occ for read-then write, with incremental retries#35192aljoscha wants to merge 11 commits intoMaterializeInc:mainfrom
aljoscha wants to merge 11 commits intoMaterializeInc:mainfrom
Conversation
|
Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone. PR title guidelines
Pre-merge checklist
|
1675464 to
2cb8e6d
Compare
We now use SUBSCRIBE instead of PEEK to maintain the desired set of updates that need to be written. We also don't acquire locks on tables but instead optimistically try and write our updates at the timestamp right at our current subscribe frontier. Additionally, we take the opportunity this provides and move the sequencing code from the coordinator main loop to the frontend, similar to how we have done that for peeks in frontend_peek.rs. Work towards MaterializeInc/database-issues#6686 Implementation of https://github.com/MaterializeInc/materialize/blob/63645b72e83ee26d2cfa99d25d773a06e6accb74/doc/developer/design/20260210_incremental_occ_read_then_write.md resolve conflicts in zykrxonm
For read-then-write with constant SELECT expressions (e.g. INSERT INTO t SELECT generate_series(...)), the subscribe finishes immediately (empty upper antichain) since the result doesn't depend on any table state. Submit these as blind writes where the coordinator picks the timestamp via the oracle during group commit. Blind writes acquire table write locks in group commit, same as regular user writes, to maintain serializability guarantees that other components depend on. Adds SubscribeFinished variant to PeekResponseUnary so the frontend RTW loop can distinguish a finished subscribe from an unexpected channel close. Key types: - Command::AttemptWrite: submits a write from the frontend RTW loop (timestamped or blind depending on write_ts) - WriteResult: result of the write attempt - PendingWriteTxn::InternalBlindWrite: blind write variant in group commit
resolve conflicts
resolve conflicts
resolve conflicts
resolve conflicts
865091f to
22a54a2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We now use SUBSCRIBE instead of PEEK to maintain the desired set of
updates that need to be written. We also don't acquire locks on tables
but instead optimistically try and write our updates at the timestamp
right at our current subscribe frontier.
Additionally, we take the opportunity this provides and move the
sequencing code from the coordinator main loop to the frontend, similar
to how we have done that for peeks in frontend_peek.rs.
Work towards https://github.com/MaterializeInc/database-issues/issues/6686
Implementation of https://github.com/MaterializeInc/materialize/blob/63645b72e83ee26d2cfa99d25d773a06e6accb74/doc/developer/design/20260210_incremental_occ_read_then_write.md