On Fri, Mar 31, 2023 at 4:17 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: >
+ * This is needed for logical decoding on standby. Indeed the "problem" is that + * WalSndWaitForWal() waits for the *replay* LSN to increase, but gets woken up + * by walreceiver when new WAL has been flushed. Which means that typically + * walsenders will get woken up at the same time that the startup process + * will be - which means that by the time the logical walsender checks + * GetXLogReplayRecPtr() it's unlikely that the startup process already replayed + * the record and updated XLogCtl->lastReplayedEndRecPtr. + * + * The ConditionVariable XLogRecoveryCtl->replayedCV solves this corner case. IIUC we are introducing condition variables as we can't rely on current wait events because they will lead to spurious wakeups for logical walsenders due to the below code in walreceiver: XLogWalRcvFlush() { ... /* Signal the startup process and walsender that new WAL has arrived */ WakeupRecovery(); if (AllowCascadeReplication()) WalSndWakeup(); Is my understanding correct? Can't we simply avoid waking up logical walsenders at this place and rather wake them up at ApplyWalRecord() where the 0005 patch does conditionvariable broadcast? Now, there doesn't seem to be anything that distinguishes between logical and physical walsender but I guess we can add a variable in WalSnd structure to identify it. -- With Regards, Amit Kapila.