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

From Amit Kapila
Subject Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Date
Msg-id CAA4eK1+_pA2gpJAWjmg3SZYZU+nx3SMGmBF+FfUpyk-Xv=ttbQ@mail.gmail.com
Whole thread Raw
In response to Re: POC: enable logical decoding when wal_level = 'replica' without a server restart  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
List pgsql-hackers
On Thu, Oct 16, 2025 at 11:10 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Oct 16, 2025 at 1:41 AM Amit Kapila <amit.kapila16@gmail.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.

>
> 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.
>

Right, I would prefer a new PMSIGNAL for this. But OTOH, we are not
sure how frequent or important this case is in the field, so maybe it
is not worth adding more code for it. However, we should at least add
a comment for future optimization. One semi-related point is if one
would like to write a regression test for this behaviour, the test
timing would be unpredictable.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: Question for coverage report