Zhanxiang (Patrick) Huang

The recovery mechanism is being refactored. See https://github.com/risingwavelabs/risingwave/pull/5396#issuecomment-1249395039 Do we need to wait for that before working on this issue?

cc @wangrunji0408 Feel free to take a look. We can discuss how to integrate this with madsim.

> Unfortunately, this poll-based method is not reliable. Because try_send_compaction_request is actually a hint, the scheduler may not schedule tasks for a request (NoTask). If we poll after try_send_compaction_request, the...

> > After try_send_compaction_request is triggered, we can wait for some time (e.g. 5s) and poll both compaction task assignment and version delta. If none of them has changed, we...

We can still generate multiple chunks. Atomicity can be guaranteed by not injecting barrier in between these chunks.

Strong +1. Btw, do we have a case that notification version increases without epoch increases? In other words, can we use epoch as the notification version?

I saw `Mon Sep 12 07:33:48 UTC 2022 [risedev]: Program exited with 137` in the compute node log. I think exit code 137 means OOM.

> I'm not sure if the new policy will cause a fairness problem among compaction groups because when a task is completed, the next compaction task is triggered on the...


> LGTM. > > BTW, if we do not want to maintain this complex unpin logic: we can simply send unpin request when receive epoch update. Agree. We can merge...