Skip to content

adapter: use occ for read-then write, with incremental retries#35192

Draft
aljoscha wants to merge 11 commits intoMaterializeInc:mainfrom
aljoscha:adapter-read-then-write-occ-incremental
Draft

adapter: use occ for read-then write, with incremental retries#35192
aljoscha wants to merge 11 commits intoMaterializeInc:mainfrom
aljoscha:adapter-read-then-write-occ-incremental

Conversation

@aljoscha
Copy link
Contributor

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

@github-actions
Copy link

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

  • Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
  • Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
  • Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

@aljoscha aljoscha force-pushed the adapter-read-then-write-occ-incremental branch 4 times, most recently from 1675464 to 2cb8e6d Compare February 27, 2026 13:59
aljoscha added 11 commits March 16, 2026 16:29
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
@aljoscha aljoscha force-pushed the adapter-read-then-write-occ-incremental branch from 865091f to 22a54a2 Compare March 16, 2026 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant