wal_level change in PostgreSQL 14 creates standby compatibility uncertainty after pg_upgrade

Resolution

To maintain compatibility and enable logical replication capabilities on a standby server after the primary has been switched to wal_level = logical, the standby must be restarted. A configuration reload is insufficient because wal_level is a postmaster-start parameter.

A full reinitialization via initdb or pg_basebackup is not required, provided the standby is already synchronized with the primary. The standby can continue to receive WAL streams from a primary with a higher wal_level than its own; however, it cannot independently support logical decoding or certain standby-side operations until its own parameter is updated and the process is restarted.

Technical Explanation

In PostgreSQL 14, while the default wal_level shifted to logical, pg_upgrade preserves the settings of the source cluster to ensure stability. This often results in a primary and standby remaining at replica level despite the version jump.

The wal_level parameter controls how much information is written to the Write-Ahead Log. Because this affects the fundamental structure of the WAL records generated by the server, it cannot be changed dynamically. When you update this value in postgresql.conf, the change remains dormant until the PostgreSQL service is fully restarted, triggering a new postmaster process.

Required Steps for Compatibility

1. Update Configuration: Modify postgresql.conf on the standby server: wal_level = logical.
2. Restart Service: Perform a full restart of the PostgreSQL service on the standby.
3. Verify Setting: Run the following command to confirm the change is active:

   SHOW wal_level;

Verification and Safety

To ensure the standby is healthy and compatible with the primary's current WAL stream, check the primary's replication slots:

SELECT slot_name, active, restart_lsn FROM pg_replication_slots;

If the standby's wal_level is lower than the primary's, the physical replication will typically continue to function (as logical is a superset of replica). However, you should monitor the standby logs for any "insufficient information" errors if you attempt to use logical features on the standby side.

Diagnostic Detail Needed: Are you intending to use the standby as a source for logical replication (via a promoted standby), or simply ensuring it can receive the primary's logical-level WAL stream?