On Wed, Sep 10, 2025 at 12:15 AM Masahiko Sawada <sawada.mshk@gmail.com> 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.
