> On Mar 31, 2026, at 16:59, Chao Li <[email protected]> wrote: > > > >> On Mar 31, 2026, at 15:28, Chao Li <[email protected]> wrote: >> >> Hi, >> >> There is an XXX comment in WalSndWait(): >> ``` >> * XXX: A desirable future improvement would be to add support for CVs >> * into WaitEventSetWait(). >> ``` >> >> I have been exploring a possible approach for that. This patch is a PoC that >> adds ConditionVariable support to WaitEventSet. This v1 is mainly intended >> to gather feedback on the design, so I have only done some basic testing so >> far, such as a normal logical replication workflow. >> >> I’d like to highlight a few key points about the design: >> >> 1. In the current WalSndWait(), although it prepares to sleep on a >> ConditionVariable, it does not actually check whether the CV has been >> signaled. In this PoC, I kept that same behavior. However, I tried to make >> the WaitEventSet support for CVs generic, so that if we want to add actual >> signal checking in the future, that would be possible. >> >> 2. To keep the design generic, this patch introduces a new wait event type, >> WL_CONDITION_VARIABLE. A WL_CONDITION_VARIABLE event occupies a position in >> the event array, similar to latch and socket events. When a CV is signaled, >> the corresponding WL_CONDITION_VARIABLE event is returned in occurred_events. >> >> 3. The WaitEventSet APIs AddWaitEventToSet() and ModifyWaitEvent() are >> extended to support CVs by adding one more parameter “cv" to both APIs. The >> downside of this approach is that all call sites of these two APIs need to >> be updated. I also considered adding separate APIs for CVs, such as >> AddWaitEventToSetForCV() and ModifyWaitEventForCV(), since CVs do not rely >> on the kernel and it might therefore make sense to decouple them from socket >> and latch handling. But for v1, I chose the more generic approach. I’d be >> interested in hearing comments on this part of the design. >> >> 4. One important point is that this patch extends the WaitEventSet >> abstraction, not the underlying kernel wait primitives. A ConditionVariable >> is still a userspace/shared-memory concept, but with this design it can >> participate in the same waiting framework as sockets and latches. I think >> that is useful because it allows mixed waits to be handled through one >> interface. >> >> Here is the v1 patch. >> >> Best regards, >> -- >> Chao Li (Evan) >> HighGo Software Co., Ltd. >> https://www.highgo.com/ >> >> >> >> >> <v1-0001-Add-condition-variable-support-to-WaitEventSetWai.patch> > > > I just noticed that I missed checking in my last edit when switching to the > other branch, so attaching an updated v1. > > Best regards, > -- > Chao Li (Evan) > HighGo Software Co., Ltd. > https://www.highgo.com/ > > > > > <v1-0001-Add-condition-variable-support-to-WaitEventSetWai.patch>
PFA v2 - fixed a CI failure from contrib/postgres_fdw. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v2-0001-Add-condition-variable-support-to-WaitEventSetWai.patch
Description: Binary data
