> On Apr 2, 2026, at 15:38, Chao Li <[email protected]> wrote: > > > >> 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>
Fixed a CI test failure and rebased. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v3-0001-Add-condition-variable-support-to-WaitEventSetWai.patch
Description: Binary data
