Unexpected Standby Shutdown on sync_replication_slots change

Hello,

I'm not sure if it's a bug but I've encountered an unexpected behavior when
dynamically changing the sync_replication_slots parameter on a PostgreSQL
17 standby server. Instead of logging an error and continuing to run, the
standby instance shuts down with a FATAL error, which is not the
anticipated behavior for a dynamic parameter change, especially when the
documentation doesn't indicate such an outcome.

Steps to Reproduce

1.

Set up a physical replication between two PostgreSQL 17.5 instances.
2.

Ensure wal_level on the primary (and consequently on the standby) is set
to replica.
3.

Start both the primary and standby instances, confirming replication is
active.
4.

On the *standby* instance, dynamically change the sync_replication_slots
parameter (I have run the following query: ALTER SYSTEM SET
sync_replication_slots = 'on'; followed by SELECT pg_reload_conf();)

Expected Behavior

I expected the standby instance to continue running and log an error
message (similar to how hot_standby_feedback behaves when not enabled,
e.g., a loop of LOG: replication slot synchronization requires
"hot_standby_feedback" to be enabled). A FATAL error leading to an
unexpected shutdown for a dynamic parameter change on a running standby is
not the anticipated behavior. The documentation for sync_replication_slots
also doesn't indicate that a misconfiguration or incompatible wal_level
would lead to a shutdown.

Actual Behavior

Upon attempting to set sync_replication_slots to on on the standby with
wal_level set to replica, the standby instance immediately shuts down with
the following log messages:

LOG: database system is ready to accept read-only connections
LOG: started streaming WAL from primary at 0/3000000 on timeline 1
LOG: received SIGHUP, reloading configuration files
LOG: parameter "sync_replication_slots" changed to "on"
FATAL: replication slot synchronization requires "wal_level" >= "logical"

Environment

-

*PostgreSQL Version:* 17.5