When using logical replication on top of physical replication in a Patroni-managed PostgreSQL cluster, a manual failover can cause data loss on lagging logical replicas — even when the physical cluster itself loses no data. This happens because Patroni creates a new logical replication slot on the promoted replica using the current LSN, skipping any WAL changes the logical replica hadn't yet consumed. The post walks through a hands-on reproduction of the problem using iptables to simulate a leader failure, then explains two solutions: using PostgreSQL 17's native replication slot synchronization (with `sync_replication_slots`, `hot_standby_feedback`, `synchronized_standby_slots`, and the `failover` slot parameter), and upgrading to Patroni 4.1+ which natively avoids interfering with failover-labeled slots. Together, these allow fault-tolerant logical replication using only built-in PostgreSQL features.
