Horton

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

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.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>
Date: 2025-10-16T17:41:36Z
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 Thu, Oct 16, 2025 at 1:46 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Sawada-san,
>
> > It's not harmful in practice. I've considered waking up the postmaster
> > with a new PMSignalReason, but I thought it's overkill to introduce a
> > new reason just to wake up the postmaster. If there is a convenient
> > way, I'd like to use that.
>
> It's not straightforward, but can we reuse SIGHUP signal for the purpose? This
> operation actually modifies the GUC parameter wal_level. One downside is that
> postmaster will propagated it to all processes, which is not required.

I think there is a big drawback that the server ends up reloading all
other GUC parameters, which might not be an expected timing for users.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com