A PostgreSQL logical replication slot represents a stream of changes that a consumer can replay in order. The slot also acts as a retention promise. While it exists, PostgreSQL keeps the WAL needed by its consumer. An abandoned slot can therefore turn a small replication mistake into a disk-capacity incident, a failed backup, or an outage that affects every database in the cluster.
Slots have an identifier that is unique across the cluster. Creating and dropping them is not ordinary application work. PostgreSQL restricts replication-slot functions to superusers and users with the REPLICATION privilege. That is an administrative boundary, not a reason to give every integration the same role. A managed replication service only needs the operations required to manage its own subscription, while a human operator may need the ability to inspect and remove stale slots.
The visible problem is usually an inactive slot with a growing retained-WAL distance. pg_replication_slots exposes the slot name, type, database, active state, restart LSN, confirmed flush LSN and other state that varies by PostgreSQL version. Use those fields to answer three questions: is a consumer connected, where is it reading, and how much WAL is being retained? Capacity monitoring should alert on both absolute free space and the age or distance of retention, because a fixed byte threshold may be harmless on one cluster and severe on another.
Do not drop a slot merely because it is inactive. A consumer may be paused for maintenance, a failover may have moved the subscriber, or a temporary network partition may be recovering. First identify the owner from the subscription definition, deployment inventory, or secret manager. Check whether the subscription is expected to exist and whether the consumer is healthy. If the owner is gone, record the slot name, database, LSN and retained-WAL estimate before removal. After removal, verify that retained WAL actually falls and that no subscription or failover process still depends on it.
Logical failover slots add another coordination requirement. When a standby takes over, slot state must match the active primary. If failover slots are configured, the publication side, standby settings and monitoring should be tested together. A slot that exists on paper but is not synchronized is not a recovery plan. A slot copied without the corresponding consumer state can be either useless or dangerous, depending on which LSN the subscriber resumes from.
Network access to logical replication is a security boundary as well. Use TLS for remote consumers, identify the subscriber, and restrict who can create publications or read changes from sensitive tables. PostgreSQL row filters and column lists can narrow a publication, but they do not replace grants, network policy, or a review of what the downstream system stores. A replicated event stream may copy customer data into a second trust domain with different administrators.
A useful operating procedure has four steps. Inventory subscriptions and their slots together. Monitor active state and retained WAL with an owner label. Require an owner and an expiry review for paused or temporary slots. Remove only an orphan after a second source confirms that no subscriber will return. The same procedure should be exercised during a failover drill, not written after the first disk alert.
The security issue is easy to overlook because the database is doing exactly what it was asked to do. A slot protects changes for a consumer. The team must decide how long that protection should last, who can create it, and how an abandoned promise is discovered before it consumes the cluster.