On Wed, Jan 7, 2026 at 9:55 PM Ashutosh Bapat <[email protected]> wrote: > > On Thu, Jan 8, 2026 at 10:51 AM Amit Kapila <[email protected]> wrote: > > > > On Thu, Jan 8, 2026 at 10:42 AM Ashutosh Bapat > > <[email protected]> wrote: > > > > > > On Thu, Jan 8, 2026 at 5:17 AM Masahiko Sawada <[email protected]> > > > wrote: > > > > > > > > On Wed, Jan 7, 2026 at 4:56 AM Matthias van de Meent > > > > <[email protected]> wrote: > > > > > > > > > > On Fri, 19 Dec 2025 at 08:51, Masahiko Sawada <[email protected]> > > > > > wrote: > > > > > > > > > > > > On Thu, Dec 18, 2025 at 9:14 PM Peter Smith <[email protected]> > > > > > > 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.
The superuser can drop logical slots anytime to turn off logical decoding. I think it's not some decision that the superuser has no way to control. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
