Skip to content

adapter: retire linearize reads from AdvanceTimelines to fix residual starvation#37512

Draft
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:linearize-advance-timelines
Draft

adapter: retire linearize reads from AdvanceTimelines to fix residual starvation#37512
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:linearize-advance-timelines

Conversation

@antiguru

@antiguru antiguru commented Jul 8, 2026

Copy link
Copy Markdown
Member

Follow-up to #37316. That fix stopped the linearize re-check from starving group commit, but left a residual priority inversion: in the biased coordinator select, both the branch enqueuing a pending strict serializable read and the re-check branch sit below cmd_rx, so a sustained write flood starves retirement even while the same flood advances the oracle past the read's timestamp on the higher group commit branch. The read stays pending until the flood drains. Repro and evidence in #37316 (comment).

Reordering only relocates the victim. Instead, retirement rides its causal signal: message_linearize_reads now runs from the Message::AdvanceTimelines handler, which group commit emits on the top-priority internal channel after advancing the oracle. The enqueue branch moves above cmd_rx (safe because it is causally downstream of cmd_rx and cannot outrun it). The re-check branch stays below cmd_rx as the idle-period path.

Adds def-'s LinearizeReadStarvation parallel-benchmark scenario as a regression guard and records the priority-inversion class in the adapter guide.

Draft: local build is currently broken, so the benchmark RED→GREEN has not been re-run locally. Left as draft pending that verification.

🤖 Generated with Claude Code

A strict serializable read that picks a timestamp ahead of the oracle
becomes a pending linearize read that retires only once the oracle
advances. The oracle advances only via group commit. In the coordinator's
biased select, both the branch that enqueues a pending read and the branch
that re-checks pending reads sat below user command intake (`cmd_rx`), so a
sustained write flood kept `cmd_rx` runnable and starved retirement, even as
the same flood advanced the oracle past the read's timestamp on the higher
group commit branch. Reads stayed pending until the flood drained.

Reordering the select only relocates the victim. Instead couple retirement
to its causal signal: run `message_linearize_reads` from the
`Message::AdvanceTimelines` handler, which group commit emits on the
top-priority internal channel after advancing the oracle. Move the enqueue
branch above `cmd_rx`, which is safe because enqueue is causally downstream
of `cmd_rx` and cannot outrun it. The re-check branch stays below `cmd_rx`
as the idle-period low-latency path.

Add the `LinearizeReadStarvation` parallel-benchmark scenario as a
regression guard and record the priority-inversion class in the adapter
guide.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@antiguru

antiguru commented Jul 8, 2026

Copy link
Copy Markdown
Member Author

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