DROP_SUBSCRIPTION(7pg15)

💖 NAME 💖

Okay bestie, welcome to the DROP_SUBSCRIPTION page from the PostgreSQL 15.19 Documentation — manual page DROP SUBSCRIPTION(7). The official NAME vibe is DROP_SUBSCRIPTION — remove a subscription. That's it, that's the whole mission. 🫶

✨ SYNOPSIS ✨

DROP SUBSCRIPTION [ IF EXISTS ] name [ CASCADE | RESTRICT ]

🌸 DESCRIPTION 🌸

DROP SUBSCRIPTION removes a subscription from the database cluster. Simple as that, no cap. 💅

Important vibe check: a subscription can only be dropped by a superuser. So if you're not that girl, this command is not your moment. 😭

Also, DROP SUBSCRIPTION cannot be executed inside a transaction block if the subscription is associated with a replication slot. (You can use ALTER SUBSCRIPTION to unset the slot.) This is a real caveat, bestie, not just dramatic foreshadowing. 💀

🎀 PARAMETERS 🎀

• IF EXISTS — do not throw an error if the subscription does not exist. A notice is issued in this case. So it's like "okay bestie, we move" instead of a whole meltdown. 🙈
• name — the name of a subscription to be dropped. Exactly what it sounds like. 🍓
• CASCADE, RESTRICT — these key words do not have any effect, since there are no dependencies on subscriptions. They're just kinda there, matching the syntax vibe. 💅

🔥 NOTES 🔥

Okay this is the part where you need to pay attention, because it's giving "important plot twist." 👑

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. Basically: clean up your remote mess, or the resources stay reserved. 🧚

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. Not a soft fail, bestie — it will fail. 😭

To proceed in this situation, first disable the subscription by executing ALTER SUBSCRIPTION ... DISABLE, and then disassociate it from the replication slot by executing ALTER SUBSCRIPTION ... SET (slot_name = NONE). 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 31.2.1. This is your "please don't let the disk fill up" reminder, fr fr. 💀

If a subscription is associated with a replication slot, then DROP SUBSCRIPTION cannot be executed inside a transaction block. Yes, this again — it's that serious. 🫶

🌈 EXAMPLES 🌈

Drop a subscription:

DROP SUBSCRIPTION mysub;

Iconic. Short. Does exactly what it says on the tin. ✨

💜 COMPATIBILITY 💜

DROP SUBSCRIPTION is a PostgreSQL extension. So it's a PostgreSQL-specific slay, periodt. 💅

🦋 SEE ALSO 🦋

• CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7))
• ALTER SUBSCRIPTION (ALTER_SUBSCRIPTION(7))

---

Signing off from the PostgreSQL 15.19 docs, dated 2026 — stay subscribed to good vibes only, bestie. 💖🎀🫶