I found that after the fix I proposed [1], there is a possibility that effective_wal_level could be logical after the promotion, even after the logical slots are dropped [2]. Steps:
0. Setup a streaming replication system, and both nodes had a replication slot 1. Attached to the startup and added a break at UpdateLogicalDecodingStatusEndOfRecovery 2. Sent a promotion request to the standby. Startup would stop 3. Established a connection to the standby. 4. Attached to the backend and added a break at ReplicationSlotDrop 5. Tried to drop the replication slot on the standby. Backend would stop 6. Moved the startup till WaitForProcSignalBarrier(). Note that allow_status_change was still off. 7. Detached from the backend process. 8. Detached from the startup process. This can happen because UpdateLogicalDecodingStatusEndOfRecovery() decided to keep wal_level logical, and upcoming DisableLogicalDecodingIfNecessary() cannot disable it. allow_status_change should be true for the case. I considered an approach not to release lock while waiting the ProcSignal, but other processes cannot not read and update xlog_logical_info. [1]: https://www.postgresql.org/message-id/OSCPR01MB14966B8F6F728F3FB4B05BFDBF5E7A%40OSCPR01MB14966.jpnprd01.prod.outlook.com [2] ``` postgres=# SELECT pg_is_in_recovery(); pg_is_in_recovery ------------------- f (1 row) postgres=# SHOW effective_wal_level ; effective_wal_level --------------------- logical (1 row) postgres=# SELECT count(*) FROM pg_replication_slots ; count ------- 0 (1 row) ``` Best regards, Hayato Kuroda FUJITSU LIMITED
