Can I drop a replication slot safely?

Safely, yes, provided you have established what was consuming it. The command refuses while a consumer is attached, so an accidental drop under a live replica is not possible. What is possible, and common, is dropping a slot whose consumer is temporarily away, which quietly converts a reconnectable outage into a rebuild from a fresh copy of the data.

The question to answer first

Not “is this slot inactive” but “is the thing that created it coming back”. Those are different, and the slot cannot tell you.

A physical slot for a standby that is being rebuilt anyway is free to drop. A physical slot for a standby that is merely powered off for maintenance is not, because when it returns it will ask for a position the primary no longer has. A logical slot for a decommissioned subscriber is free. A logical slot for a change-data pipeline that is paused during a deployment is emphatically not: dropping it loses the position in the stream, and there is no way to resume from where it was. The consumer starts again from a snapshot, which on a large table is hours and a second conversation about when.

So the checks are: nothing attached now, nothing that has been attached recently, and a named owner who agrees the consumer is gone. The inactivity timestamp that makes the second of those answerable arrived in PostgreSQL 17; before that, the honest proxy is when the consumer was last seen in its own logs.

After the drop, and the case for not needing one

Space is not returned at the moment of the drop. The retained segments become recyclable and disappear at the next checkpoint, so a disk under pressure recovers a minute or two later rather than immediately. If you cannot wait, requesting a checkpoint brings it forward.

It is worth asking whether the drop is necessary at all. A ceiling on per-slot retention lets the server invalidate a runaway slot on its own, with the same consequence for the consumer and none of the timing pressure on you. That behaviour, and the several distinct reasons it triggers, are in replication slot invalidation.

One case where dropping is exactly wrong: a major-version upgrade. PostgreSQL 17 can carry logical slots across an upgrade, which removes the resync that earlier versions forced, and dropping the slots beforehand out of habit gives that back. For deciding whether a lagging slot is a slot problem or a replica problem, replication lag and slot health separates the two.