Thread

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

Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-28T00:38:50Z

Hi,

On Sun, Feb 15, 2026 at 11:38 AM Andres Freund <andres@anarazel.de> 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 <andres@anarazel.de> 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