feat(meta): avoid sending inject barrier request to all workers#24361
Merged
feat(meta): avoid sending inject barrier request to all workers#24361
Conversation
652545b to
ec342f4
Compare
yezizp2012
approved these changes
Jan 12, 2026
| generate_series, | ||
| '{"orders": {"id": 1, "price": "2.30", "customer_id": 2}}'::jsonb | ||
| FROM generate_series(1, 50000); | ||
| FROM generate_series(1, 10000); |
Member
There was a problem hiding this comment.
What is the reason for the modification here? To decrease the CI time?
Contributor
Author
There was a problem hiding this comment.
Yes, without it, the ci backfill test will be timed out.
yezizp2012
pushed a commit
that referenced
this pull request
Jan 21, 2026
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.

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Previously we had to send
InjectBarrierRequestto all worker nodes, even if there is no actors on the nodes. We implement it in this way because: 1. we used to broadcast some global information via the request, and 2. there was a mysterious panic in CI.For 1, we don't broadcast anything in the request anymore. For 2, the mysterious panic was because of the following. We have two important fields in
InjectBarrierRequest,actor_ids_to_collectandtable_ids_to_sync. When handling a command, we have two steps,pre_applyandpost_apply.actor_ids_to_collectshould include the remaining actors betweenpre_applyandpost_apply, whiletable_ids_to_syncshould only include the table_ids afterpost_apply. Therefore, for example, when handling a drop command, the dropped fragments still exist afterpre_apply, and have been removed afterpost_apply, and then the actors of the fragments should be included in theactor_ids_to_collect, while the table_ids should not be included intable_ids_to_sync.To handle this, in this PR, we additionally pass a param
nodes_to_sync_tableininject_barrier. For a node that has actors on it, but not innodes_to_sync_table, we will set an emptytable_ids_to_syncinInjectBarrierRequest.Checklist
Documentation
Release note