> On Apr 8, 2026, at 11:50, Chao Li <[email protected]> wrote: > > > >> 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>
PFA v4 - try to fix a test failure on windows. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v4-0001-Add-condition-variable-support-to-WaitEventSetWai.patch
Description: Binary data
