ALTER_SUBSCRIPTION(7pg16)

✨ NAME ✨

Okay so this is the ALTER SUBSCRIPTION(7) page from the PostgreSQL 16.15 docs, and we're about to make it make sense. ALTER_SUBSCRIPTION literally changes the definition of a subscription. That's the whole vibe. 💖

---

🌸 SYNOPSIS 🌸

Here's every form you can use, bestie — no cap, they're all valid:

ALTER SUBSCRIPTION name CONNECTION 'conninfo'
ALTER SUBSCRIPTION name SET PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ADD PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name DROP PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name REFRESH PUBLICATION [ WITH ( refresh_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ENABLE
ALTER SUBSCRIPTION name DISABLE
ALTER SUBSCRIPTION name SET ( subscription_parameter [= value] [, ... ] )
ALTER SUBSCRIPTION name SKIP ( skip_option = value )
ALTER SUBSCRIPTION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SUBSCRIPTION name RENAME TO new_name

---

🦋 DESCRIPTION 🦋

ALTER SUBSCRIPTION can change most of the subscription properties that you'd normally set in CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)). Think of it as the edit button for your replication setup. 🛍️

Okay so permissions, bestie — you literally must own the subscription to use ALTER SUBSCRIPTION. To rename a subscription or alter the owner, you need CREATE permission on the database. And to alter the owner, you also have to be able to SET ROLE to the new owning role. Also: if the subscription has password_required=false, only superusers can modify it. Periodt. 🔐

When refreshing a publication, we remove the relations that are no longer part of the publication, and we also remove the table synchronization slots if there are any. Why? Because it's necessary to remove those slots so the resources allocated for the subscription on the remote host are released. If PostgreSQL can't remove the slots due to a network breakdown or some other error, it will report an error. To proceed in that situation, the user either needs to retry the operation or disassociate the slot from the subscription and drop the subscription as explained in DROP SUBSCRIPTION (DROP_SUBSCRIPTION(7)). So dramatic, but necessary. 😭

Real talk: ALTER SUBSCRIPTION ... REFRESH PUBLICATION and ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... with the refresh option set to true cannot be executed inside a transaction block. These commands also cannot be executed when the subscription has two_phase commit enabled, unless copy_data is false. Wanna know the actual two-phase state? Check the subtwophasestate column of pg_subscription. iykyk. 👀

---

🎀 PARAMETERS 🎀

• name — the name of a subscription whose properties are to be altered. Like, which subscription are we editing? 💅
• CONNECTION 'conninfo' — this clause replaces the connection string originally set by CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)). See there for more information. It's the ultimate connection glow-up. ✨
• SET PUBLICATION publication_name, ADD PUBLICATION publication_name, DROP PUBLICATION publication_name — these forms change the list of subscribed publications. SET replaces the entire list of publications with a new list, ADD adds additional publications to the list of publications, and DROP removes the publications from the list of publications. We allow non-existent publications to be specified in the ADD and SET variants so that users can add those later. See CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)) for more information. By default, this command will also act like REFRESH PUBLICATION. Iconic behavior. 👑

publication_option specifies additional options for this operation. The supported options are:

• refresh (boolean) — when false, the command will not try to refresh table information. REFRESH PUBLICATION should then be executed separately. The default is true. 🫶

Additionally, the options described under REFRESH PUBLICATION may be specified, to control the implicit refresh operation.

• REFRESH PUBLICATION — fetch missing table information from publisher. This will start replication of tables that were added to the subscribed-to publications since CREATE SUBSCRIPTION or the last invocation of REFRESH PUBLICATION. Like a refresh button for your replication. 🔄

refresh_option specifies additional options for the refresh operation. The supported options are:

• copy_data (boolean) — specifies whether to copy pre-existing data in the publications that are being subscribed to when the replication starts. The default is true. Previously subscribed tables are not copied, even if a table's row filter WHERE clause has since been modified. See Notes for details of how copy_data = true can interact with the origin parameter. See the binary parameter of CREATE SUBSCRIPTION for details about copying pre-existing data in binary format.

• ENABLE — enables a previously disabled subscription, starting the logical replication worker at the end of the transaction. We love a comeback era. 💖
• DISABLE — disables a running subscription, stopping the logical replication worker at the end of the transaction. Sometimes you gotta pause. ✋
• SET ( subscription_parameter [= value] [, ... ] ) — this clause alters parameters originally set by CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)). See there for more information. The parameters that can be altered are slot_name, synchronous_commit, binary, streaming, disable_on_error, password_required, run_as_owner, and origin. Only a superuser can set password_required = false. Periodt. 🔐
• SKIP ( skip_option = value ) — skips applying all changes of the remote transaction. If incoming data violates any constraints, logical replication will stop until it is resolved. By using the ALTER SUBSCRIPTION ... SKIP command, the logical replication worker skips all data modification changes within the transaction. This option has no effect on the transactions that are already prepared by enabling two_phase on the subscriber. After the logical replication worker successfully skips the transaction or finishes a transaction, the LSN (stored in pg_subscription.subskiplsn) is cleared. See Section 31.5 for the details of logical replication conflicts. So useful when things get messy. 💀

skip_option specifies options for this operation. The supported option is:

• lsn (pg_lsn) — specifies the finish LSN of the remote transaction whose changes are to be skipped by the logical replication worker. The finish LSN is the LSN at which the transaction is either committed or prepared. Skipping individual subtransactions is not supported. Setting NONE resets the LSN. No subtransaction skipping, bestie — that's not the vibe. 🚫

• new_owner — the user name of the new owner of the subscription. Handing over the keys. 🔑
• new_name — the new name for the subscription. Rename era. 🎀

When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE. So WITH (refresh) is lowkey WITH (refresh = true). Slay. 💅

---

🔥 EXAMPLES 🔥

Change the publication subscribed by a subscription to insert_only:

ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;

Disable (stop) the subscription:

ALTER SUBSCRIPTION mysub DISABLE;

---

⭐ COMPATIBILITY ⭐

ALTER SUBSCRIPTION is a PostgreSQL extension. That's the whole note. 💅

---

🌈 SEE ALSO 🌈

• CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7))
• DROP SUBSCRIPTION (DROP_SUBSCRIPTION(7))
• CREATE PUBLICATION (CREATE_PUBLICATION(7))
• ALTER PUBLICATION (ALTER_PUBLICATION(7))

---

This page is from PostgreSQL 16.15, dated 2026, and it's literally the ALTER SUBSCRIPTION(7) manual page. Go forth and alter those subscriptions, bestie. 💜✨