On Wed, Sep 10, 2025 at 12:15 AM Masahiko Sawada <[email protected]> wrote: > > I've reread his report. IIUC what happened in his test scenario was; > while he was restarting the primary server (to make > wal_level='replica' effect), the slotsync worker exited due to a > connection error. Then after the primary started up, with the patch, > the slotsync worker was not launched again, whereas it was launched > again without the patch. This is because with the patch, the standby > disables the logical decoding when replaying the STATUS_CHANGE record. > If the primary enables logical decoding again, the STATUS_CHANGE > record with logical_decoding=true is replicated to the standby and it > launches the slotsync worker again. That is, the slotsync worker > launches based on the standby's effective_wal_level. On the other > hand, before the patch, the slotsync worker is launched solely based > on the standby's wal_level. Therefore, it launches but doesn't do > anything in this case (as the primary should not have any logical > slot). I thought it makes sense that we don't launch the slotsync > worker when effective_wal_level is 'replica', but is your suggestion > that the slotsync worker needs to be launched only when the standby's > wal_level is logical regardless of effective_wal_level? >
No, the patch's behavior is good. I was thinking whether we can change it even for HEAD and then the patch's behavior will match with HEAD. But I think that may not be as straight-forward because standby may not have that information readily available. Anyway, if there is no simple way to change HEAD's behavior then we can leave that as it is. -- With Regards, Amit Kapila.
