wal_level change in PostgreSQL 14 creates standby compatibility uncertainty after pg_upgrade

Goal

Determine whether a standby server that was initially set up with wal_level=replica must be restarted, reinitialized, or simply have its wal_level parameter changed and reloaded after the primary’s wal_level is switched to logical during a pg_upgrade to PostgreSQL 14, in order to maintain logical replication compatibility.

Constraints and Uncertainty

PostgreSQL 14 changed the default wal_level from replica to logical, but pg_upgrade preserves the existing wal_level on upgraded clusters, creating mixed environments. The documentation does not clearly state if a standby that retains wal_level=replica after the primary’s change requires a restart, a fresh initdb, or merely a configuration reload, leaving administrators unsure whether replication lag or logical slot creation failures will occur.

Open Questions

• Does the standby need to be restarted after changing its wal_level to logical?
• Is a full reinitialization with initdb required for the standby to match the primary’s wal_level?
• Can simply updating wal_level in postgresql.conf and issuing a reload resolve the compatibility issue?