--- title: "DROP SUBSCRIPTION" id: sql-dropsubscription pg_version: "20devel" --- # DROP SUBSCRIPTION — remove a subscription ## Synopsis ``` DROP SUBSCRIPTION [ IF EXISTS ] name [ CASCADE | RESTRICT ] ``` ## Description `DROP SUBSCRIPTION` removes a subscription from the database cluster. To execute this command the user must be the owner of the subscription. `DROP SUBSCRIPTION` cannot be executed inside a transaction block if the subscription is associated with a replication slot. (You can use [`ALTER SUBSCRIPTION`](sql-altersubscription.md) to unset the slot.) ## Parameters **`IF EXISTS`** Do not throw an error if the subscription does not exist. A notice is issued in this case. **`name`** The name of a subscription to be dropped. **`CASCADE`**, **`RESTRICT`** These key words do not have any effect, since there are no dependencies on subscriptions. ## Notes When dropping a subscription that is associated with a replication slot on the remote host (the normal state), `DROP SUBSCRIPTION` will connect to the remote host and try to drop the replication slot (and any remaining table synchronization slots) as part of its operation. This is necessary so that the resources allocated for the subscription on the remote host are released. If this fails, either because the remote host is not reachable or because the remote replication slot cannot be dropped or does not exist or never existed, the `DROP SUBSCRIPTION` command will fail. To proceed in this situation, first disable the subscription by executing [`ALTER SUBSCRIPTION ... DISABLE`](sql-altersubscription.md#sql-altersubscription-params-disable), and then disassociate it from the replication slot by executing [`ALTER SUBSCRIPTION ... SET (slot_name = NONE)`](sql-altersubscription.md#sql-altersubscription-params-set). After that, `DROP SUBSCRIPTION` will not attempt to drop the subscription's own replication slot. It may still connect to the publisher to drop internally-created table synchronization slots if some table synchronization is left unfinished; if the publisher is unreachable, those slots (and the main slot, if it still exists) must be dropped manually. Otherwise it/they will continue to reserve WAL and might eventually cause the disk to fill up. See also [Section 29.2.1](logical-replication-subscription.md#logical-replication-subscription-slot). If a subscription is associated with a replication slot, then `DROP SUBSCRIPTION` cannot be executed inside a transaction block. If a conflict log table exists for the subscription (that is, when [`conflict_log_destination`](sql-createsubscription.md#sql-createsubscription-params-with-conflict-log-destination) is set to `table` or `all`), `DROP SUBSCRIPTION` automatically drops the associated conflict log table. ## Examples Drop a subscription: DROP SUBSCRIPTION mysub; ## Compatibility `DROP SUBSCRIPTION` is a PostgreSQL extension. ## See Also [CREATE SUBSCRIPTION](sql-createsubscription.md), [ALTER SUBSCRIPTION](sql-altersubscription.md)