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

On Fri, 19 Dec 2025 at 08:51, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Dec 18, 2025 at 9:14 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > I checked the v35/v36 patch diffs, and I also have no further review comments.
> >
>
> Thank you for reviewing the patch!
>
> I'm going to push it early next week if there are no major comments.
>
> Regards,

Hi,

Sorry for the belated reply. I noticed this patch got committed, and
after reading its commit message (and now, code) I'm concerned that
I'm now unable to disable wal_level=logical without removing streaming
replication as feature.
When I configure wal_level=replica, to me that means to NOT enable
wal_level=logical, and that means that I do *not* want the increased
overhead in my cluster's table updates that is associated with
wal_level=logical (but still want to be able to have streaming
replication).

I had expected the topical feature to be implemented through changing
wal_level to PGC_SIGHUP from PGC_POSTMASTER (and then propagating that
through a similar system), which would've required an explicit
agreement of the cluster owner to increase the WAL overhead in favour
of being able to do logical decoding. However, by making
effective_wal_level controlled by CREATE_REPLICATION_SLOT, this guc is
suddenly effectively set-able by users with the REPLICATION privilege,
which it previously wasn't. And I don't trust my physical subscribers'
roles to _not_ also create a logical replication slot.

So, sorry I'm late, but I don't agree with the way this decides to
change the effective wal level. It elevates REPLICATION users to be
able to control wal_level without actually going through the security
controls of the system. And no, granting SET ON PARAMETER wal_level
for REPLICATION roles isn't a solution IMO - replication roles
shouldn't decide which types of replication are allowed in the
cluster, only the system owner (and its explicit delegates) should.

NB. I'm not opposed to changing wal_level in a running cluster, and I
do think that the current xact+checkpoint -based approach to selecting
the local effective_wal_level is fine, as well as standby picking up
the primary's current setting; it's the trigger condition for the
decision to change effective_wal_level that I have problems with.

Kind regards,

Matthias van de Meent