From 1fae4072e5f045ca8d30fb7e42b6c8e63a9e1680 Mon Sep 17 00:00:00 2001 From: Peter Smith Date: Wed, 8 Sep 2021 14:30:09 +1000 Subject: [PATCH v3] PG Docs - Create Subscription - options groupings. The subscription parameters are rearranged into two groups: a) those that control what happens during Create Subscription b) those that control the replication behavior --- doc/src/sgml/ref/create_subscription.sgml | 127 ++++++++++++++++-------------- 1 file changed, 70 insertions(+), 57 deletions(-) diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 702934e..3c0bf37 100644 --- a/doc/src/sgml/ref/create_subscription.sgml +++ b/doc/src/sgml/ref/create_subscription.sgml @@ -92,17 +92,38 @@ CREATE SUBSCRIPTION subscription_nameWITH ( subscription_parameter [= value] [, ... ] ) - This clause specifies optional parameters for a subscription. The - following parameters are supported: + This clause specifies optional parameters for a subscription. + + + The following subscription_parameter names control what happens during subscription creation: + - copy_data (boolean) + connect (boolean) - Specifies whether the existing data in the publications that are - being subscribed to should be copied once the replication starts. - The default is true. + Specifies whether the CREATE SUBSCRIPTION + should connect to the publisher at all. Setting this to + false will change default values of + enabled, create_slot and + copy_data to false. + + + + It is not allowed to combine connect set to + false and enabled, + create_slot, or copy_data + set to true. + + + + Since no connection is made when this option is set + to false, the tables are not subscribed, and so + after you enable the subscription nothing will be replicated. + It is required to run + ALTER SUBSCRIPTION ... REFRESH PUBLICATION in order + for tables to be subscribed. @@ -147,37 +168,12 @@ CREATE SUBSCRIPTION subscription_name - - synchronous_commit (enum) - - - The value of this parameter overrides the - setting within this - subscription's apply worker processes. The default value - is off. - + - - It is safe to use off for logical replication: - If the subscriber loses transactions because of missing - synchronization, the data will be sent again from the publisher. - + + The following subscription_parameter names control the replication behavior: - - A different setting might be appropriate when doing synchronous - logical replication. The logical replication workers report the - positions of writes and flushes to the publisher, and when using - synchronous replication, the publisher will wait for the actual - flush. This means that setting - synchronous_commit for the subscriber to - off when the subscription is used for - synchronous replication might increase the latency for - COMMIT on the publisher. In this scenario, it - can be advantageous to set synchronous_commit - to local or higher. - - - + binary (boolean) @@ -201,33 +197,16 @@ CREATE SUBSCRIPTION subscription_name - connect (boolean) + copy_data (boolean) - Specifies whether the CREATE SUBSCRIPTION - should connect to the publisher at all. Setting this to - false will change default values of - enabled, create_slot and - copy_data to false. - - - - It is not allowed to combine connect set to - false and enabled, - create_slot, or copy_data - set to true. - - - - Since no connection is made when this option is set - to false, the tables are not subscribed, and so - after you enable the subscription nothing will be replicated. - It is required to run - ALTER SUBSCRIPTION ... REFRESH PUBLICATION in order - for tables to be subscribed. + Specifies whether the existing data in the publications that are + being subscribed to should be copied once the replication starts. + The default is true. + streaming (boolean) @@ -237,9 +216,41 @@ CREATE SUBSCRIPTION subscription_name + + + + synchronous_commit (enum) + + + The value of this parameter overrides the + setting within this + subscription's apply worker processes. The default value + is off. + + + + It is safe to use off for logical replication: + If the subscriber loses transactions because of missing + synchronization, the data will be sent again from the publisher. + + + + A different setting might be appropriate when doing synchronous + logical replication. The logical replication workers report the + positions of writes and flushes to the publisher, and when using + synchronous replication, the publisher will wait for the actual + flush. This means that setting + synchronous_commit for the subscriber to + off when the subscription is used for + synchronous replication might increase the latency for + COMMIT on the publisher. In this scenario, it + can be advantageous to set synchronous_commit + to local or higher. + + two_phase (boolean) @@ -267,6 +278,8 @@ CREATE SUBSCRIPTION subscription_name + + -- 1.8.3.1