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. Greetings, Andres Freund
