ALTER SUBSCRIPTION
change the definition of a subscription
Synopsis
ALTER SUBSCRIPTION NAME SERVER SERVERNAME
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 REFRESH SEQUENCES
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 can be specified in sql-createsubscription.
You must own the subscription to use ALTER SUBSCRIPTION. To rename a subscription or alter the owner, you must have CREATE permission on the database. In addition, to alter the owner, you must be able to SET ROLE to the new owning role. If the subscription has password_required=false, only superusers can modify it.
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. It is necessary to remove these slots so that the resources allocated for the subscription on the remote host are released. If due to network breakdown or some other error, PostgreSQL is unable to remove the slots, an error will be reported. To proceed in this situation, the user either needs to retry the operation or disassociate the slot from the subscription and drop the subscription as explained in sql-dropsubscription.
Commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION, ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... with refresh option as true, ALTER SUBSCRIPTION ... SET (failover = true|false) and ALTER SUBSCRIPTION ... SET (two_phase = false) cannot be executed inside a transaction block.
Commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... with refresh option as true also cannot be executed when the subscription has two_phase commit enabled, unless copy_data is false. See column subtwophasestate of pg_subscription to know the actual two-phase state.
Parameters
- name
- The name of a subscription whose properties are to be altered.
SERVERservername- This clause replaces the foreign server or connection string originally set by sql-createsubscription with the foreign server servername.
CONNECTION 'conninfo'- This clause replaces the foreign server or connection string originally set by sql-createsubscription with the connection string conninfo.
SET PUBLICATIONpublication_name,ADD PUBLICATIONpublication_name,DROP PUBLICATIONpublication_name-
These forms change the list of subscribed publications.
SETreplaces the entire list of publications with a new list,ADDadds additional publications to the list of publications, andDROPremoves the publications from the list of publications. We allow non-existent publications to be specified inADDandSETvariants so that users can add those later. See sql-createsubscription for more information. By default, this command will also act likeREFRESH PUBLICATION.publication_option specifies additional options for this operation. The supported options are:
REFRESH PUBLICATION-
Fetch missing table and sequence information from the publisher. This will start replication of tables that were added to the subscribed-to publications since
CREATE SUBSCRIPTIONor the last invocation ofREFRESH PUBLICATION.The system catalog pg_subscription_rel is updated to record all tables and sequences known to the subscription, that are still part of the publication.
refresh_option specifies additional options for the refresh operation. The supported options are:
copy_data(boolean)-
Specifies whether to copy pre-existing data for tables and synchronize sequences 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
WHEREclause has since been modified.Previously subscribed sequences are not re-synchronized. To do that, use
ALTER SUBSCRIPTION ... REFRESH SEQUENCES.See Sequence Definition Mismatches for recommendations on how to handle any warnings about sequence definition differences between the publisher and the subscriber, which might occur when
copy_data = true.See Notes for details of how
copy_data = truecan interact with theoriginparameter.See the
binaryparameter ofCREATE SUBSCRIPTIONfor details about copying pre-existing data in binary format.
REFRESH SEQUENCES-
Re-synchronize sequence data with the publisher. Unlike
ALTER SUBSCRIPTION ... REFRESH PUBLICATION, which synchronizes the subscription's set of sequences with the publication (adding new and removing dropped sequences),REFRESH SEQUENCESwill re-synchronize the sequence data for all currently subscribed sequences without changing which sequences are subscribed. RunREFRESH PUBLICATIONfirst if the publication's set of sequences has changed.See Sequence Definition Mismatches for recommendations on how to handle any warnings about sequence definition differences between the publisher and the subscriber.
See Refreshing Out-of-Sync Sequences for recommendations on how to identify and handle out-of-sync sequences.
ENABLE- Enables a previously disabled subscription, starting the logical replication worker at the end of the transaction.
DISABLE- Disables a running subscription, stopping the logical replication worker at the end of the transaction.
SET (subscription_parameter[=value] [, ... ] )-
This clause alters parameters originally set by sql-createsubscription. 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,origin,failover,two_phase,retain_dead_tuples,max_retention_duration, andwal_receiver_timeout. Only a superuser can setpassword_required = false.When altering the
slot_name, thefailoverandtwo_phaseproperty values of the named slot may differ from the counterpartfailoverandtwo_phaseparameters specified in the subscription. When creating the slot, ensure the slot propertiesfailoverandtwo_phasematch their counterpart parameters of the subscription. Otherwise, the slot on the publisher may behave differently from what these subscription options say: for example, the slot on the publisher could either be synced to the standbys even when the subscription'sfailoveroption is disabled or could be disabled for sync even when the subscription'sfailoveroption is enabled.The
failover,two_phase, andretain_dead_tuplesparameters can only be altered when the subscription is disabled.When altering
two_phasefromtruetofalse, the backend process reports an error if any prepared transactions done by the logical replication worker (from whentwo_phaseparameter was stilltrue) are found. You can resolve prepared transactions on the publisher node, or manually roll them back on the subscriber, and then try again. The transactions prepared by logical replication worker corresponding to a particular subscription have the following pattern: “pg_gid_%u_%u” (parameters: subscriptionoid, remote transaction idxid). To resolve such transactions manually, you need to roll back all the prepared transactions with corresponding subscription IDs in their names. Applications can checkpg_prepared_xactsto find the required prepared transactions. After thetwo_phaseoption is changed fromtruetofalse, the publisher will replicate the transactions again when they are committed.If the
retain_dead_tuplesoption is altered tofalseand no other subscription has this option enabled, the replication slot named “pg_conflict_detection”, created to retain dead tuples for conflict detection, will be dropped. 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 ... SKIPcommand, 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 enablingtwo_phaseon the subscriber. After the logical replication worker successfully skips the transaction or finishes a transaction, the LSN (stored inpg_subscription.subskiplsn) is cleared. See Conflicts for the details of logical replication conflicts.skip_option specifies options for this operation. The supported option is:
- new_owner
- The user name of the new owner of the subscription.
- new_name
- The new name for the subscription.
When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE.
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.
See Also
sql-createsubscription, sql-dropsubscription, sql-createpublication, sql-alterpublication