Re: POC: enable logical decoding when wal_level = 'replica' without a server restart - Mailing list pgsql-hackers

On Thu, Oct 16, 2025 at 1:41 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Oct 15, 2025 at 9:50 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Wed, Oct 15, 2025 at 3:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Tue, Oct 14, 2025 at 11:40 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > >
> > > > On Tue, Oct 14, 2025 at 2:24 AM shveta malik <shveta.malik@gmail.com> wrote:
> > > > >
> > > > > Thanks. I was testing slot-sync worker flow and noticed that even if
> > > > > 'sync_replication_slots' is enabled, it takes quite some time (1-2
> > > > > mins) for slot sync worker to start. On noticing
> > > > > XLOG_LOGICAL_DECODING_STATUS_CHANGE, isn't there a way to (or
> > > > > shouldn't we) wakeup postmaster to start slotsync worker immediately?
> > > > >
> > > > > Logs for timestamps reference:
> > > > >
> > > > > 2025-10-14 14:41:32.852 IST [208475] LOG:  replication slot
> > > > > synchronization requires "effective_wal_level" >= "logical" on the
> > > > > primary
> > > > > 2025-10-14 14:41:32.852 IST [208475] HINT:  To enable logical decoding
> > > > > on primary, set "wal_level" >= "logical" or create at least one
> > > > > logical slot when "wal_level" = "replica".
> > > > > 2025-10-14 14:41:35.499 IST [208481] LOG:  update logical decoding status to 1
> > > > > 2025-10-14 14:41:35.499 IST [208481] CONTEXT:  WAL redo at 0/03000060
> > > > > for XLOG/LOGICAL_DECODING_STATUS_CHANGE: true
> > > > > 2025-10-14 14:42:53.611 IST [208529] LOG:  slot sync worker started
> > > > > ------
> > > >
> > > > I think that this particular situation happened because the postmaster
> > > > was sleeping and didn't have any tasks. If a new connection comes in
> > > > or the existing connection exits, the postmaster launches the slotsync
> > > > worker. I believe it would not be a serious issue in practice.
> > > >
> > >
> > > Right, but OTOH, do we see any harm if we wake up the postmaster on
> > > such an event? It shouldn't happen frequently to matter either way
> > > though.
> >
> > It's not harmful in practice. I've considered waking up the postmaster
> > with a new PMSignalReason, but I thought it's overkill to introduce a
> > new reason just to wake up the postmaster. If there is a convenient
> > way, I'd like to use that.
> >
>
> Do you think we can use PMSIGNAL_BACKGROUND_WORKER_CHANGE for this
> reason? Otherwise, I see different processes have separate reasons
> like PMSIGNAL_START_AUTOVAC_LAUNCHER, PMSIGNAL_START_AUTOVAC_WORKER,
> or PMSIGNAL_START_WALRECEIVER to signal postmaster for similar
> purpose.

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. So it would be okay in principle to keep
the slotsync worker running while wal_level='replica'. A drawback
would be that users always using wal_level='replica' would
unnecessarily launch the slotsync worker but they can turn off
sync_replication_slots GUC parameter.

Regards,

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