Horton

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

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, shveta malik <shveta.malik@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-09-17T11:19:31Z
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 Tue, Sep 16, 2025 at 11:49 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Sep 16, 2025 at 1:30 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > When user is dropping a temporary slot, we should disable the
> > decoding. The lazy behaviour should be for ERROR or session_exit
> > cases.
>
> I think it might be worth discussing whether to use lazy behavior in
> all cases.
>

Agreed.

> There are several advantages:
>
> - It mitigates the risk of connection timeouts during a logical slot
> drop or a subscription drop.
> - In scenarios involving frequent creation and deletion of logical
> slots (such as during initial data synchronization), it could
> potentially avoid the issue of a frequent switch on and off.
>
> On the other hand, drawbacks are:
>
> - users would have to wait for effective_wal_level to get decreased to
> 'replica' somehow.
> - makes the checkpointer more busy in addition to its checkpointing job.
> - it could take a longer time to disable logical decoding if the
> checkpoint is busy with a checkpointing job.
>

This last point in drawback could hurt performance of systems for a
longer time when that was really not required. It should be okay to
use lazy behavior in all cases when we can do that in a predictable
time. The other background process to consider doing lazy processing
is the launcher whose role is to launch apply workers for subscription
and maintain a conflict_slot (if required). Now, because disabling
logical_info could also take longer time in worst cases, the
launcher's own tasks can become unpredictable. Also, if tomorrow, we
decide to support dynamically changing wal_level from minimal to some
upper level, the launcher won't be the appropriate process.

The other idea could be to have a new auxiliary process to disable
logical_info lazily. It is arguable if we just have a separate process
for this purpose but we have previously discussed some other tasks for
such a process like removal of old_serialized_snapshots and
old_logical_ rewrite_map files. See [1]. If we agree to have a
separate process for this purpose then disabling logical_info in all
cases sounds okay to me.

[1] - https://www.postgresql.org/message-id/20230217234344.GA3357392%40nathanxps13

-- 
With Regards,
Amit Kapila.