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

On Thu, Jan 8, 2026 at 10:42 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Thu, Jan 8, 2026 at 5:17 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Wed, Jan 7, 2026 at 4:56 AM Matthias van de Meent
> > <boekewurm+postgres(at)gmail(dot)com> wrote:
> > >
> > > 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.
> > >
> >
> > 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.

--
With Regards,
Amit Kapila.