Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

On Fri, Oct 17, 2025 at 5:07 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Oct 17, 2025 at 12:47 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Oct 16, 2025 at 9:07 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > On Fri, Oct 17, 2025 at 8:55 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > >
> > > > On Thu, Oct 16, 2025 at 11:10 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > > >
> > > > > On Thu, Oct 16, 2025 at 1:41 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > > >
> > > > >
> > > > > Using PMSIGNAL_BACKGROUND_WORKER_CHANGE sounds mis-using since the
> > > > > slotsync worker is not a background worker nor logical decoding
> > > > > activation is not related to bgworkers.
> > > > >
> > > > > An alternative idea is to launch the slotsync worker if wal_level
> > > > > value on the standby is >=replica, that is, always launch it on the
> > > > > standby if sync_replication_slots is on. Even with and without the
> > > > > patch, we don't shutdown the slotsync worker even if logical decoding
> > > > > gets disabled on the standby.
> > > > >
> > > >
> > > > Are you talking about the case when wal_level on primary has reduced
> > > > below logical and user will get the following message on standby:
> > > > "logical decoding on standby requires \"wal_level\" >= \"logical\" on
> > > > the primary"? If so, the slight difference in this case is that
> > > > standby still has wal_level logical.
> > > >
> > >
> > > I believe what Sawada-san meant is that even when effective_wal_level
> > > = replica on a standby, we should still allow the slot-sync worker to
> > > start if 'sync_replication_slots' is enabled. This is because we
> > > currently do not stop the worker when effective_wal_level on the
> > > standby changes from logical to replica, so allowing it to start in
> > > this case maintains consistent behavior. That said, my preference is
> > > to not start the slot-sync worker if effective_wal_level is less than
> > > logical. As I understand, this is already the behavior implemented in
> > > the current patch.
> >
> > Exactly. Thank you for clarifying my comment.
> >
> > >
> > > Regarding the scenario where effective_wal_level changes from logical
> > > to replica on a standby, my vote is to explicitly shut down the
> > > slot-sync worker in such cases. I don't see any benefit in keeping it
> > > running. But this can be handled in a separate patch as it is not
> > > directly concerned with this patch.
> >
> > If the last logical slot on the primary is a failover slot,
> > STATUS_CHANGE with logical_decoding=false could reach the standby
> > before the slotsync worker drops the corresponding slot. In this case,
> > if we shutdown the slotsync upon replaying that WAL record, the synced
> > (and invalidated) slot could remain. It might be one potential benefit
> > that we keep the slotsync worker running even when wal_level='replica'
> > (at least until one more synchronization cycle is done).
> >
>
> Okay, I will think more on this.
>
> > >
> > > Next is, when effective_wal_level changes from replica to logical,
> > > should we wake up the postmaster to immediately start the slot-sync
> > > worker? My vote is yes, but if implementing this introduces too much
> > > complexity, especially considering it's a rare scenario, we could
> > > leave it as is. In that case, the slot-sync worker would still start,
> > > but possibly with a delay of up to 1-2 minutes when the postmaster is
> > > sleeping.
> >
> > After checking other codes, I found that we simply send SIGUSR1 to the
> > postmaster in pg_promote(). I think we can use it.
> >
>
> Okay.

I've attached the updated patches.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com