Skip to content
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

ct: split persist writes into a separate operator #30147

Closed
wants to merge 1 commit into from

Conversation

danhhz
Copy link
Contributor

@danhhz danhhz commented Oct 22, 2024

This does two things:

  • Makes it straightforward to support readonly mode.
  • Sets up swapping in storage's multi-worker persist_sink, once it supports truncating on CaA failure and is less entagled with storage.

It feels a little silly to write a throwaway single-worker persist_sink, but it's nice that the multi-worker one should be a drop-in replacement.

Touches https://github.com/MaterializeInc/database-issues/issues/8427

Motivation

  • This PR refactors existing code.

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • 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).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

This does two things:
- Makes it straightforward to support readonly mode.
- Sets up swapping in storage's multi-worker persist_sink, once it
  supports truncating on CaA failure and is less entagled with storage.

It feels a little silly to write a throwaway single-worker persist_sink,
but it's nice that the multi-worker one should be a drop-in replacement.
@danhhz danhhz requested review from antiguru and teskje October 22, 2024 21:41
@danhhz danhhz requested a review from a team as a code owner October 22, 2024 21:41
Copy link
Contributor

@teskje teskje left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Some of the names/comments have become stale now, would be good to fix those too!

Comment on lines +378 to +379
let (to_append, button0) =
continual_task_sink(&name, to_append, append_times, as_of, write_handle());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Now that this operator is not a sink anymore, can we call it something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same thought, but didn't think of anything good for the name. Any ideas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I'm drawing a blank as well :/

Comment on lines +497 to +499
if let Some(new_upper) = new_upper.as_option() {
cap.downgrade(new_upper);
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we need to drop the capability when new_upper is the empty frontier? Are we guaranteed to take the "Inputs exhausted, shutting down" branch next in that case?

@@ -394,11 +395,10 @@ fn continual_task_sink<G: Scope<Timestamp = Timestamp>>(
append_times: Collection<G, (), Diff>,
as_of: Antichain<Timestamp>,
write_handle: impl Future<Output = WriteHandle<SourceData, (), Timestamp, Diff>> + Send + 'static,
start_signal: StartSignal,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: There is a outdated comment a couple lines below that talks about "The start_signal below...", which is gone now.

@danhhz
Copy link
Contributor Author

danhhz commented Oct 30, 2024

(I might hold off on merging this until @def- finishes the first full round of CT testing. It doesn't seem super pressing and I'm a little worried that it'll introduce some silly small bug and add another hiccup to the timeline.)

@danhhz
Copy link
Contributor Author

danhhz commented Jan 13, 2025

Cleaning up old PRs

@danhhz danhhz closed this Jan 13, 2025
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.

2 participants