Normally, the remote replication slot is created automatically when the
- subscription is created using CREATE SUBSCRIPTION and it
+ subscription is created using
+ CREATE SUBSCRIPTION and it
is dropped automatically when the subscription is dropped using
- DROP SUBSCRIPTION . In some situations, however, it can
+ DROP SUBSCRIPTION .
+ In some situations, however, it can
be useful or necessary to manipulate the subscription and the underlying
replication slot separately. Here are some scenarios:
When dropping a subscription, the replication slot should be kept.
This could be useful when the subscriber database is being moved to a
different host and will be activated from there. In that case,
- disassociate the slot from the subscription using ALTER
- SUBSCRIPTION before attempting to drop the subscription.
+ disassociate the slot from the subscription using
+ ALTER SUBSCRIPTION
+ before attempting to drop the subscription.
If a subscription is affected by this problem, the only way to resume
replication is to adjust one of the column lists on the publication
side so that they all match; and then either recreate the subscription,
- or use ALTER SUBSCRIPTION ... DROP PUBLICATION to
+ or use
+ ALTER SUBSCRIPTION ... DROP PUBLICATION to
remove one of the offending publications and add it again.
the replication origin name can be found from the server log (LSN 0/14C0378 and
replication origin pg_16395 in the above case). The
transaction that produced the conflict can be skipped by using
- ALTER SUBSCRIPTION ... SKIP with the finish LSN
+ ALTER SUBSCRIPTION ... SKIP
+ with the finish LSN
(i.e., LSN 0/14C0378). The finish LSN could be an LSN at which the transaction
is committed or prepared on the publisher. Alternatively, the transaction can
also be skipped by calling the
pg_replication_origin_advance() function.
Before using this function, the subscription needs to be disabled temporarily
- either by ALTER SUBSCRIPTION ... DISABLE or, the
+ either by
+ ALTER SUBSCRIPTION ... DISABLE or, the
subscription can be used with the
disable_on_error
option. Then, you can use pg_replication_origin_advance()
ADD and DROP clauses will add and
remove one or more tables/schemas from the publication. Note that adding
tables/schemas to a publication that is already subscribed to will require an
- ALTER SUBSCRIPTION ... REFRESH PUBLICATION action on the
+
+ ALTER SUBSCRIPTION ... REFRESH PUBLICATION action on the
subscribing side in order to become effective. Note also that
DROP TABLES IN SCHEMA will not drop any schema tables
that were specified using
Parameters
-
+ id="sql-altersubscription-params-name">
name
-
+ id="sql-altersubscription-params-connection">
CONNECTION 'conninfo '
-
+ id="sql-altersubscription-params-setadddrop-publication">
SET PUBLICATION publication_name
ADD PUBLICATION publication_name
DROP PUBLICATION publication_name
-
+ id="sql-altersubscription-params-refresh-publication">
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
+ since
+ CREATE SUBSCRIPTION or
the last invocation of REFRESH PUBLICATION .
-
+ id="sql-altersubscription-params-enable">
ENABLE
-
+ id="sql-altersubscription-params-disable">
DISABLE
-
+ id="sql-altersubscription-params-set">
SET ( subscription_parameter [= value ] [, ... ] )
-
+ id="sql-altersubscription-params-skip">
SKIP ( skip_option = value )
-
+ id="sql-altersubscription-params-new-owner">
new_owner
-
+ id="sql-altersubscription-params-new-name">
new_name
DROP SUBSCRIPTION cannot be executed inside a
transaction block if the subscription is associated with a replication
- slot. (You can use <command>ALTER SUBSCRIPTION> to unset the
+ slot. (You can use <link linkend="sql-altersubscription">ALTER SUBSCRIPTION > to unset the
slot.)
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 , and then disassociate
+
+ ALTER SUBSCRIPTION ... DISABLE , and then disassociate
it from the replication slot by executing
- ALTER SUBSCRIPTION ... SET (slot_name = NONE) .
+
+ ALTER SUBSCRIPTION ... SET (slot_name = NONE) .
After that, DROP SUBSCRIPTION will no longer attempt any
actions on a remote host. Note that if the remote replication slot still
exists, it (and any related table synchronization slots) should then be