Hi, On Sun, Feb 15, 2026 at 11:38 AM Andres Freund <[email protected]> wrote: > > Hi, > > On 2026-02-15 19:08:54 +0100, Matthias van de Meent wrote: > > On Sun, 15 Feb 2026 at 18:31, Andres Freund <[email protected]> wrote: > > > On 2026-02-15 18:18:30 +0100, Matthias van de Meent wrote: > > > > However, with the current code, the DBA can't make the choice whether > > > > to allow logical replication or not, at least not without reverting to > > > > wal_level=minimal -- which removes effectively all HA features. No > > > > amount of monitoring or rights management can make a DBA safely use > > > > the features enabled by wal_level=replica without risking additional > > > > overhead with effective_wal_level=logical; a very significant change > > > > from PG versions up to 18, where you could safely run your server like > > > > that. > > > > > > I really don't understand this argument. If you are worried about WAL > > > volume: > > > Any user with rights to create a table or do DML can increase WAL volume > > > to an > > > arbitrary degree. And that's actually harder to pinpoint than seeing that > > > a > > > new replication slot has been created, since the user creating a lot of > > > WAL > > > with a new table can do so in a transaction that creates and drops the > > > table, > > > thereby never having any visible stats. > > > > > > What is the realistic scenario in which you trust a user enough to have > > > REPLICATION rights, i.e. a right to read *all* data in the server *and* to > > > hold back horizons arbitrarily far > > > > Which horizons would be held back arbitrarily far? Automation > > triggered by monitoring can solve practically all of that horizon > > issue; unless you're referring to the lack of horizon invariant > > enforcement; in which case indeed but that's a separate issue I'd like > > to see solved, too, but that's not relevant in this thread. > > You can solve the undesired-logical-slot case just as well that way. > > > > >, but you are worried about them creating > > > logical replication slots? I don't think it exists. > > > > I'd be fine with giving a physical replication slot (with relevant > > roles) to an externally managed replica if they needed access to all > > of the data, and had a significant read-only workload - better > > outsource that RO workload and kick out the slot whenever it > > misbehaves than front the bill for a (much) larger instance. > > > > However, I wouldn't be fine with that role then using that replication > > permission to create a logical slot. And because I won't have > > wal_level=logical configured in pg18- they can't; but with pg19+ it > > looks like they'll be allowed to even if I explicitly chose not to > > enable it. > > I don't understand why the answer for the logical slot isn't the same as for > the physical slot. Kick them out if they misbehave. > > If you give non-trustable users replication permissions, you're in deep > trouble regardless of physical or logical slots. > > > And again, any users with more than the bare minimum of permissions can cause > arbitrarily much WAL to be emitted, in very hard to identify ways. If you're > concerned about users triggering too high WAL usage, ISTM your time would be > much better spent introducing infrastructure to track per-session or even per > user WAL generation.
I noticed that this point still remains as an open item for PG19. I agree with the points Andres and Amit made: the REPLICATION privilege already grants very powerful capabilities, including the ability to read all data via physical streaming and to hold back horizons. A user trusted with REPLICATION is already trusted enough that allowing them to create a logical slot does not represent a fundamentally new class of risk. As Andres pointed out, any user with more than the bare minimum of permissions can cause arbitrarily high WAL volume in hard-to-identify ways. If the concern is about detecting and responding to unexpected overhead the better path would be improving monitoring infrastructure (e.g. per-session or per-user WAL tracking) rather than restricting logical slot creation itself. And we already have backend-level WAL statistics. Since there have been no further objections since then, I'd like to propose closing this open item as "Non-bugs". Any comments? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
