Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

On Thu, May 21, 2026 at 10:02 PM Imran Zaheer <imran(dot)zhir(at)gmail(dot)com> wrote:
>
> Hi
>
> The recent support for dynamic toggling of logical decoding (67c2097)
> disables logical
> decoding if no logical slots are present. But the repack command doesn't seem to
> coordinate with this toggling. The effective_wal_level is not
> decreasing after using repack concurrently.
>
> postgres=# show effective_wal_level;
> effective_wal_level
> ---------------------
> replica
> (1 row)
>
> postgres=# create table foo(a int primary key);
> CREATE TABLE
> postgres=# REPACK (CONCURRENTLY) foo;
> 2026-05-21 20:46:25.423 PKT [1591896] LOG: logical decoding is
> enabled upon creating a new logical replication slot
> 2026-05-21 20:46:25.634 PKT [1591896] LOG: logical decoding found
> consistent point at 0/018F36D0
> 2026-05-21 20:46:25.634 PKT [1591896] DETAIL: There are no running
> transactions.
> REPACK
> postgres=# select slot_name from pg_replication_slots;
> slot_name
> -----------
> (0 rows)
>
> postgres=# show effective_wal_level;
> effective_wal_level
> ---------------------
> logical
> (1 row)
>
>
> The server has to be restarted in order to decrease the
> effective_wal_level. REPACK CONCURRENTLY uses a temporary slot that is
> dropped at the time of cleanup, but logical decoding is not disabled.
>
> This may be related to both commits, 28d534e and 67c2097
>
> The attached patch adds the `RequestDisableLogicalDecoding` call to
> `repack_cleanup_logical_decoding` after the replication slot is
> dropped so the checkpointer will take care of it..
>

Thanks for reporting the issue. I agree with both the problem
statement and the proposed fix.

The fix LGTM. The only point I’d like to discuss is whether it would
make more sense for RequestDisableLogicalDecoding() to be called
directly from ReplicationSlotDropAcquired().

Currently, ReplicationSlotRelease(), ReplicationSlotDrop(), and now
repack_cleanup_logical_decoding() all invoke
RequestDisableLogicalDecoding() immediately after
ReplicationSlotDropAcquired(). Given this pattern, it may be cleaner
and less error-prone to make RequestDisableLogicalDecoding() part of
ReplicationSlotDropAcquired() itself, which could also help avoid
similar bugs in the future.

That said, one concern is that ReplicationSlotsDropDBSlots() could end
up issuing too many disable requests if there are many logical slots
in the target database, so I’m not entirely sure whether this is the
right direction. Thoughts?

Copying Sawada-san (author of the original patch) too, to share his
thoughts on this.

thanks
Shveta