DROP_SUBSCRIPTION(7pg17)

πŸ“¦ version 17.11, in opensuse-leap 16.0

πŸ’… NAME πŸ’…

okay so welcome to DROP_SUBSCRIPTION, bestie β€” the PostgreSQL 17.11 documentation page that's all about removing a subscription from your database cluster. it's cleanup era, and honestly? iconic.

✨ SYNOPSIS ✨

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

🫢 DESCRIPTION 🫢

DROP SUBSCRIPTION removes a subscription from the database cluster. no cap.

To execute this command, the user must be the owner of the subscription. owner vibes only, bestie.

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.) that's the rule β€” don't try to be slick. πŸ’…

πŸŽ€ 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, it's not here, but we move" instead of a whole error moment.
  • name β€” the name of a subscription to be dropped. literally the subscription's name.
  • CASCADE β€” these key words do not have any effect, since there are no dependencies on subscriptions. yes, for real, it's giving decorative.
  • RESTRICT β€” same situation: these key words do not have any effect, since there are no dependencies on subscriptions. no extra drama, no effect.

πŸ”₯ 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. resource release slay.

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 the vibe. 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. 😭 so yeah, clean those up. See also Section 29.2.1.

🚨 if a subscription is associated with a replication slot, then DROP SUBSCRIPTION cannot be executed inside a transaction block. that's a hard no, bestie.

🌸 EXAMPLES 🌸

Drop a subscription:

DROP SUBSCRIPTION mysub;

πŸ¦‹ COMPATIBILITY πŸ¦‹

DROP SUBSCRIPTION is a PostgreSQL extension. periodt.

🌈 SEE ALSO 🌈


mwah πŸ’‹ this lil page is from the PostgreSQL 17.11 documentation, dated 2026, and the original footer signs off as DROP SUBSCRIPTION(7). okay bye bestie, go drop that subscription responsibly 🫢✨

πŸ“¦ where this page comes from