Replication Slots filling up disk?
Even if you specify
use_slots in Patroni's configuration, the slot will be automatically removed if the replica fails to renew it's member key in the DCS (distributed consensus store). By default this means a slot for a disappeared replica will be dropped after 30 seconds (this corresponds to the
ttl setting, which indicates how long leader and member keys will stay in the DCS)
So unless you set up the slots yourself (with you could do with Patroni's permanent replication slot feature, though I wouldn't recommend that) your replica could very well fall behind infinitely. This means that there is no way for the replica to ever catch up, because the primary has already recycled some of the WAL that would be necessary to catch up.
How to avoid falling infinitely behind
The easy way to handle this scenario is to set wal_keep_segments high enough to cover your usual downtimes (network partitions, hardware maintenance etc.).
The recommended way to handle this is by implementing centralized WAL archiving, e.g. with pgBackRest, so that the lagging replica can retrieve missing WAL from the archive.
How to recover from falling infinitely behind
If your replica ever falls too far behind and the primary has already recycled some of the WAL that would be necessary to catch up, and you don't have a WAL archive, the replica needs to be recreated.
This is very easily done running
patronictl -c /path/to/your/patroni.yaml reinit clustername membername
Depending on the
create_replica_methods that you have defined, a backup will be used to "reimage" the replica. By default this is done through pg_basebackup.