Horton

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

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2025-10-22T11:06:05Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix regression test failure when wal_level is set to minimal.

  2. Toggle logical decoding dynamically based on logical slot presence.

  3. Disallow server start with sync_replication_slots = on and wal_level < logical.

On Wed, Oct 22, 2025 at 2:58 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Oct 22, 2025 at 2:40 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> >
> > I want to discuss the create-publication case, which currently gives
> > this warning:
> >
> > postgres=# create publication pub1 for all tables;
> > WARNING:  logical decoding should be allowed to publish logical changes
> > HINT:  Before creating subscriptions, set "wal_level" >= "logical" or
> > create a logical replication slot when "wal_level" = "replica".
> > CREATE PUBLICATION
> >
> > But is this warning really necessary during publication creation?
> >
>
> On HEAD, the WARNING/HINT is as follows for the above case:
> WARNING:  "wal_level" is insufficient to publish logical changes
> HINT:  Set "wal_level" to "logical" before creating subscriptions.
>
> Shouldn't we simply change the HINT to "Set "wal_level" to "logical"
> or create a logical replication slot before creating subscriptions."?
>

My point was do we really need this WARNING considering case a) does
not need it now and case b) also gives different ERROR (cases
mentioned in previous email). But if we plan to retain the WARNING,
then I agree with the change proposed here, it looks simpler and
better.

thanks
Shveta