On Mon, Apr 3, 2023 at 4:26 AM Jeff Davis <pg...@j-davis.com> wrote: > > On Fri, 2023-03-31 at 02:50 -0700, Jeff Davis wrote: > > But if the ConditionVariableEventSleep() API is added, then I think > > we > > should change the non-recovery case to use a CV as well for > > consistency, and it would avoid the need for WalSndWakeup(). > > It seems like what we ultimately want is for WalSndWakeup() to > selectively wake up physical and/or logical walsenders depending on the > caller. For instance: > > WalSndWakeup(bool physical, bool logical) > > The callers: > > * On promotion, StartupXLog would call: > - WalSndWakeup(true, true) > * XLogFlush/XLogBackgroundFlush/XLogWalRcvFlush would call: > - WalSndWakeup(true, !RecoveryInProgress()) > * ApplyWalRecord would call: > - WalSndWakeup(switchedTLI, switchedTLI || RecoveryInProgress()) > > There seem to be two approaches to making that work: > > 1. Use two ConditionVariables, and WalSndWakeup would broadcast to one > or both depending on its arguments. > > 2. Have a "replicaiton_kind" variable in WalSnd (either set based on > MyDatabaseId==InvalidOid, or set at START_REPLICATION time) to indicate > whether it's a physical or logical walsender. WalSndWakeup would wake > up the right walsenders based on its arguments. > > #2 seems simpler at least for now. Would that work? >
Agreed, even Bertrand and myself discussed the same approach few emails above. BTW, if we have this selective logic to wake physical/logical walsenders and for standby's, we only wake logical walsenders at the time of ApplyWalRecord() then do we need the new conditional variable enhancement being discussed, and if so, why? -- With Regards, Amit Kapila.
