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

On Thu, Jan 8, 2026 at 10:51 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jan 8, 2026 at 10:42 AM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Thu, Jan 8, 2026 at 5:17 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On Wed, Jan 7, 2026 at 4:56 AM Matthias van de Meent
> > > <boekewurm+postgres@gmail.com> wrote:
> > > >
> > > > On Fri, 19 Dec 2025 at 08:51, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > > >
> > > > > On Thu, Dec 18, 2025 at 9:14 PM Peter Smith <smithpb2250@gmail.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.
> > > >
> > >
> > > Thank you for the comments.
> > >
> > > I understand the concern that users with the REPLICATION privilege can
> > > now effectively control wal_level, potentially increasing system-wide
> > > overhead. While the REPLICATION privilege already implies a high
> > > degree of trust as we allow it to take a basebackup and create a
> > > physical slot etc., I agree that this feature might elevate that power
> > > further, and we may need a mechanism to address this.
> > >
> >
> > The feature can be seen as a way for a non-superuser override the
> > decision of superuser who has no way to control it.
> >
>
> Administrators can still control via max_replications_slots but in
> general the REPLICATION privilege should be sufficient to control the
> additional performance impact it can cause.
>

I think that's not a full proof control. Often max_replication_slots
will be configured for future expansion, so its possible that someone
can create a logical replication slot in the free slot. Someone who
can create a replication slot, can drop its own physical replication
slot and create a logical replication slot. Either way overriding the
superuser.

--
Best Wishes,
Ashutosh Bapat