On Sat, Jan 31, 2026 at 5:41 PM Matthias van de Meent <[email protected]> wrote: > > On Thu, 8 Jan 2026 at 06:16, Amit Kapila <[email protected]> wrote: > > > > 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. > > > > > > > If we allow taking the entire physical data via the REPLICATION > > privilege, then the user must already be highly privileged. Such a > > user is already allowed to read every byte of data in the database via > > physical streaming. Now, such a user influencing wal_level to be > > changed from 'replica' to 'logical' is of lesser harm. > > I don't think the harm of changing wal_level from 'replica' to > 'logical' is decreased, because the harm is in the distributed > performance impact, not the access to data. A physical replication > slot does not (need to) impact the write performance of other backends > if it's sufficiently partitioned from other workloads (not configured > for syncrep, etc.), but wal_level=logical cannot be partitioned from > write workloads as it adds a non-negotiable overhead to the write > workloads of other backends, as they now needs to track more data > (identity columns) and must write more WAL. >
While it's true that wal_level = logical adds inline overhead to WAL writes, the argument that physical slots are immune from backend performance is a bit of a stretch. A physical slot that fails to advance its xmin (due to a lagging standby or a forgotten slot) creates a global performance impact via table and index bloat. This bloat increases I/O pressure and write amplification (via more index page splits, more number of FPWs, etc) for every backend on the system, often with longer-lasting consequences than the extra bytes written to WAL for logical logging. Since the REPLICATION role already has the power to degrade system performance via the xmin horizon, allowing them to toggle logical logging doesn't grant a fundamentally new 'type' of destructive power. > > I agree that it > > can lead to some non-malicious impact, like disk space (due to > > increased WAL volume), and extra CPU consumption due to extra WAL > > volume. But I think REPLICATION privilege can already lead to extra > > CPU consumption due to wal_sender activity, and even disk space by not > > letting the slot advance, which can even crash the system. > > > > Since these users already have the power to access all data and cause > > a Denial of Service (DoS) via disk exhaustion, the ability to > > "upgrade" WAL logging from replica to logical can be seen as an > > incremental addition to an already highly trusted role. I think we can > > update the documentation of the REPLICATION privilege. > > Replication slots that keep WAL from being recycled can be monitored > (and therefore, likely acted on) before the relevant problem (OOD) > occurs; which is not the case with the current effective_wal_level > implementation. One moment your tps is normal, the next moment it > drops because a role with REPLICATION added a logical slot, and you'll > have to delete it and wait for a checkpoint to revert back to replica. > The difference here is reaction time until it starts impacting > transactions. > We implemented this delayed behavior of reverting wal_level on slot_drop to keep the code simpler, otherwise, we need this delay mainly for temporary slots when the session exits abruptly. So, if required, in future, we can consider improving this delayed behavior for some common cases. -- With Regards, Amit Kapila.
