Merge pull request #2833 from EnterpriseDB/release/2022-06-21

Release: 2022-06-21

product_docs/docs/bdr/3.6/index.mdx

@@ -29,7 +29,7 @@ BDR Enterprise requires EDB Postgres Extended v11 (formerly known as 2ndQuadrant
 !!!note
   The documentation for the latest stable 3.6 release is available here:
 
-  [BDR 3.6 Enterprise Edition](https://documentation.2ndquadrant.com/bdr3-enterprise/release/latest-3.6/)
+  [BDR 3.6 Enterprise Edition](https://documentation.enterprisedb.com/bdr3-enterprise/release/latest-3.6/)
 
   **This is a protected area of our website, if you need access please [contact us](https://www.enterprisedb.com/contact)**
 !!!
@@ -52,7 +52,7 @@ BDR Standard requires PostgreSQL v10 or v11.
 !!!note
   The documentation for the latest stable 3.6 release is available here:
 
-  [BDR 3.6 Standard Edition](https://documentation.2ndquadrant.com/bdr3/release/latest-3.6/)
+  [BDR 3.6 Standard Edition](https://documentation.enterprisedb.com/bdr3/release/latest-3.6/)
 
    **This is a protected area of our website, if you need access please [contact us](https://www.enterprisedb.com/contact)**
 !!!

product_docs/docs/bdr/3.7/backup.mdx

@@ -52,7 +52,7 @@ backup and recovery of BDR.
 
 Physical backups of a node in a BDR cluster can be taken using
 standard PostgreSQL software, such as
-[Barman](https://www.2ndquadrant.com/en/resources/barman/).
+[Barman](https://www.enterprisedb.com/docs/supported-open-source/barman/).
 
 A physical backup of a BDR node can be performed with the same
 procedure that applies to any PostgreSQL node: a BDR node is just a
@@ -86,7 +86,7 @@ entirely *consistent*; a physical backup of a given node will
 provide Point-In-Time Recovery capabilities limited to the states
 actually assumed by that node (see the [Example] below).
 
-The following example shows how two nodes in the same BDR cluster might not 
+The following example shows how two nodes in the same BDR cluster might not
 (and usually do not) go through the same sequence of states.
 
 Consider a cluster with two nodes `N1` and `N2`, which is initially in
@@ -106,7 +106,7 @@ node `N1` will go through the following states:
 
 That is: node `N1` will *never* assume state `S + W2`, and node `N2`
 likewise will never assume state `S + W1`, but both nodes will end up
-in the same state `S + W1 + W2`. Considering this situation might affect how 
+in the same state `S + W1 + W2`. Considering this situation might affect how
 you decide upon your backup strategy.
 
 ### Point-In-Time Recovery (PITR)
@@ -135,7 +135,7 @@ BDR allows for changes from multiple masters, all recorded within the
 WAL log for one node, separately identified using replication origin
 identifiers.
 
-BDR allows PITR of all or some replication origins to a specific point in time, 
+BDR allows PITR of all or some replication origins to a specific point in time,
 providing a fully consistent viewpoint across all subsets of nodes.
 
 Thus for multi-origins, we view the WAL stream as containing multiple
@@ -195,7 +195,7 @@ to the original PostgreSQL PITR behaviour that is designed around the assumption
 of changes arriving from a single master in COMMIT order.
 
 !!! Note
-    This is feature is only available on EDB Postgres Extended and 
+    This is feature is only available on EDB Postgres Extended and
     Barman does not currently automatically create a `multi_recovery.conf` file.
 
 ## Restore

product_docs/docs/bdr/3.7/camo.mdx

@@ -5,4 +5,4 @@ originalFilePath: camo.md
 
 ---
 
-<AuthenticatedContentPlaceholder target="https://documentation.2ndquadrant.com/bdr3-enterprise/release/latest/camo/" topic="Commit At Most Once" />
+<AuthenticatedContentPlaceholder target="https://documentation.enterprisedb.com/bdr3-enterprise/release/latest/camo/" topic="Commit At Most Once" />

product_docs/docs/bdr/3.7/camo_clients.mdx

@@ -5,4 +5,4 @@ originalFilePath: camo_clients.md
 
 ---
 
-<AuthenticatedContentPlaceholder target="https://documentation.2ndquadrant.com/bdr3-enterprise/release/latest/camo_clients/" topic="Appendix C: CAMO Reference Client Implementations" />
+<AuthenticatedContentPlaceholder target="https://documentation.enterprisedb.com/bdr3-enterprise/release/latest/camo_clients/" topic="Appendix C: CAMO Reference Client Implementations" />

product_docs/docs/bdr/3.7/configuration.mdx

@@ -86,17 +86,17 @@ become relevant with BDR in combination with CAMO.
 
 ## pglogical Settings for BDR
 
-BDR is also affected by some of the pglogical settings as it uses 
+BDR is also affected by some of the pglogical settings as it uses
 pglogical internally to implement the basic replication.
 
--   `pglogical.track_subscription_apply` - Track apply statistics for 
+-   `pglogical.track_subscription_apply` - Track apply statistics for
     each subscription.
--   `pglogical.track_relation_apply` - Track apply statistics for each 
+-   `pglogical.track_relation_apply` - Track apply statistics for each
     relation.
 -   `pglogical.track_apply_lock_timing` - Track lock timing when tracking
     statistics for relations.
 -   `pglogical.standby_slot_names` - When using physical Standby nodes
-    intended for failover purposes, should be set to the replication 
+    intended for failover purposes, should be set to the replication
     slot(s) for each intended Standby.
 -   `pglogical.writers_per_subscription` - Default number of writers per
     subscription (in BDR this can also be changed by
@@ -228,7 +228,7 @@ Unless noted otherwise, values may be set by any user at any time.
     this setting. It is normal for some statements to result in two `WARNING`s,
     one for skipping the DML lock and one for skipping the DDL lock.
 
--   `bdr.truncate_locking` - False by default, this configuration option sets the 
+-   `bdr.truncate_locking` - False by default, this configuration option sets the
     TRUNCATE command's locking behavior. Determines whether (when true) TRUNCATE
     obeys the bdr.ddl_locking setting.
 
@@ -401,7 +401,7 @@ Unless noted otherwise, values may be set by any user at any time.
 
 -   `bdr.trace_level` - Similar to the above, this defines the log level
     to use for BDR trace messages.  Enabling tracing on all nodes of a
-    BDR cluster may help 2ndQuadrant Support to diagnose issues.
+    BDR cluster may help EDB Support to diagnose issues.
     May only be set at Postgres server start.
 
 !!! Warning
@@ -432,7 +432,7 @@ Unless noted otherwise, values may be set by any user at any time.
 -   `bdr.raft_group_max_connections` - The maximum number of connections
      across all BDR groups for a Postgres server. These connections carry
      bdr consensus requests between the groups' nodes. Default value of this
-     parameter is 100 connections. May only be set at Postgres server start.  
+     parameter is 100 connections. May only be set at Postgres server start.
 -   `bdr.backwards_compatibility` - Specifies the version to be
     backwards-compatible to, in the same numerical format as used by
     `bdr.bdr_version_num`, e.g. `30618`.  Enables exact behavior of a

product_docs/docs/bdr/3.7/eager.mdx

@@ -4,4 +4,4 @@ originalFilePath: eager.md
 
 ---
 
-<AuthenticatedContentPlaceholder target="https://documentation.2ndquadrant.com/bdr3-enterprise/release/latest/eager/" topic="Eager Replication" />
+<AuthenticatedContentPlaceholder target="https://documentation.enterprisedb.com/bdr3-enterprise/release/latest/eager/" topic="Eager Replication" />

product_docs/docs/bdr/3.7/index.mdx

@@ -44,7 +44,7 @@ provides a solution for building multi-master clusters with mesh topology.
 This means that you can write to any server and the changes will be
 sent row-by-row to all the other servers that are part of the same BDR group.
 
-BDR version 3 ("BDR3") is built on the [pglogical3](https://www.2ndquadrant.com/resources/pglogical/)
+BDR version 3 ("BDR3") is built on the [pglogical3](https://www.enterprisedb.com/docs/pglogical/latest/)
 extension. However, everything you need to
 know about BDR3 is included here and it is unnecessary, as well as potentially
 confusing, to refer to pglogical docs.

product_docs/docs/bdr/3.7/isolation_details.mdx

@@ -5,4 +5,4 @@ originalFilePath: isolation/details.md
 
 ---
 
-<AuthenticatedContentPlaceholder target="https://documentation.2ndquadrant.com/bdr3-enterprise/release/latest/isolation/details/" topic="Appendix B: Conflict Details" />
+<AuthenticatedContentPlaceholder target="https://documentation.enterprisedb.com/bdr3-enterprise/release/latest/isolation/details/" topic="Appendix B: Conflict Details" />

product_docs/docs/bdr/3.7/monitoring.mdx

@@ -319,10 +319,16 @@ So this view offers these insights into the state of a BDR system:
 The `bdr.workers` view shows BDR worker specific details, that are not
 available from `bdr.stat_activity`.
 
-The view `bdr.worker_errors` shows errors (if any) reported by any worker
-which has a problem continuing the work. Only active errors are visible in this
-view, so if the worker was having transient problems but has recovered, the
-view will be empty.
+The view `bdr.worker_errors` shows errors (if any) reported by any worker.
+BDR 3.7 depended explicitly on pglogical 3.7 as a separate extension. While
+pglogical deletes older worker errors, BDR does not aim to, given the additional
+complexity of bi-directional replication. A side effect of this dependency is
+that in BDR 3.7 some worker errors are deleted over time, while others are retained
+indefinitely. Because of this it's important to note the time of the error
+and not just the existence of one.
+Starting from BDR 4, there is a single extension, and dependency on
+pglogical as a separate extension has been removed, meaning that all worker errors
+are now retained indefinitely.
 
 ## Monitoring Global Locks
 

product_docs/docs/bdr/3.7/overview.mdx

@@ -37,7 +37,7 @@ replicate either from the master or from another standby.
 You don't have to write to all the masters, all of the time; it's
 a frequent configuration to direct writes mostly to just one master.
 However, if you just want one-way replication, the use of
-[pglogical](https://2ndquadrant.com/pglogical) may be more appropriate.
+[pglogical](https://www.enterprisedb.com/docs/pglogical/latest/) may be more appropriate.
 
 ### Asynchronous, by default
 

product_docs/docs/bdr/4/camo.mdx

@@ -557,6 +557,11 @@ the CAMO transaction uses the timestamp of the prepare on the origin
 node, which is before the transaction becomes visible on the origin
 node itself.
 
+- CAMO is not currently compatible with transaction streaming. Please
+ensure to disable transaction streaming when planning to use
+CAMO. This can be configured globally or in the BDR node group, see
+[Transaction Streaming Configuration](transaction-streaming#configuration).
+
 ## Performance implications
 
 CAMO extends the Postgres replication protocol by adding a

product_docs/docs/bdr/4/configuration.mdx

@@ -307,13 +307,15 @@ the failover candidate hadn't received it yet:
     the change. The subscribers now have inconsistent and irreconcilable states
     because the subscribers that didn't receive the commit have no way to get it.
 
-Setting `bdr.standby_slot_names` by design causes subscribers to
-lag behind the provider if the provider's failover-candidate replicas aren't
-keeping up. Monitoring is thus essential.
-
-Another use case where the `bdr.standby_slot_names` is useful is when using
-subscriber-only, to ensure that the subscriber-only node doesn't move ahead
-of any of the other BDR nodes.
+Setting `bdr.standby_slot_names` by design causes other subscribers
+not listed in there to lag behind the provider if the required number
+of listed nodes are not keeping up. Monitoring is thus essential.
+
+Another use case where `bdr.standby_slot_names` is useful is when
+using a subscriber-only node, to ensure that it does not move ahead of
+any of the regular BDR nodes. This can best be achieved by listing the
+logical slots of all regular BDR peer nodes in combination with
+setting `bdr.standby_slots_min_confirmed` to at least one.
 
 ### `bdr.standby_slots_min_confirmed`
 

product_docs/docs/bdr/4/eager.mdx

@@ -114,9 +114,10 @@ You can't combine Eager All-Node Replication with
 `synchronous_replication_availability = 'async'`. Trying to configure
 both causes an error.
 
-The Decoding Worker feature isn't currently supported in combination
-with Eager All-Node transactions. Installations using Eager must keep
-`enable_wal_decoder` disabled for the BDR node group using Eager All-Node transactions.
+Eager All-Node transactions are not currently supported in combination
+with the Decoding Worker feature nor with transaction streaming.
+Installations using Eager must keep `enable_wal_decoder` and `streaming_mode`
+disabled for the BDR node group.
 
 Synchronous replication uses a mechanism for transaction confirmation
 different from Eager. The two aren't compatible, and you must not use them

product_docs/docs/bdr/4/functions.mdx

@@ -67,6 +67,28 @@ becomes remotely visible.
 As soon as Postgres assigns a transaction id, if CAMO is enabled, this parameter is
 updated to show the transaction id just assigned.
 
+### bdr.is_node_connected
+
+#### Synopsis
+
+```sql
+bdr.is_node_connected(node_name name)
+```
+
+Returns boolean by checking if the walsender for a given peer is active
+on this node.
+
+### bdr.is_node_ready
+
+#### Synopsis
+
+```sql
+bdr.is_node_ready(node_name name, span interval DEFAULT NULL)
+```
+
+Returns boolean by checking if the lag is lower than the given span or
+lower than the `bdr.global_commit_timeout` otherwise.
+
 ## Consensus function
 
 ### bdr.consensus_disable

product_docs/docs/bdr/4/group-commit.mdx

@@ -10,7 +10,7 @@ confirm a transaction at COMMIT time.
 ## Requirements
 
 During normal operation, Group Commit is completely transparent to the
-application. Upon failover, the reconciliation phase must be
+application.  Upon failover, the reconciliation phase needs to be
 explicitly triggered or consolidated by either the application or a
 proxy in between. HARP provides native support for Group Commit and
 triggers the reconciliation phase, making this equally transparent
@@ -70,14 +70,19 @@ remote one.
 
 ```sql
 -- create sub-groups
-SELECT bdr.create_node_group(node_group_name := 'left_dc',
-                             parent_group_name := 'top_group',
-                             join_node_group := false);
-SELECT bdr.create_node_group(node_group_name := 'right_dc',
-                             parent_group_name := 'top_group',
-                             join_node_group := false);
-
--- create a commit scope with individual rules for each sub-group
+SELECT bdr.create_node_group(
+    node_group_name := 'left_dc',
+    parent_group_name := 'top_group',
+    join_node_group := false
+);
+SELECT bdr.create_node_group(
+    node_group_name := 'right_dc',
+    parent_group_name := 'top_group',
+    join_node_group := false
+);
+
+-- create a commit scope with individual rules
+-- for each sub-group
 SELECT bdr.add_commit_scope(
     commit_scope_name := 'example_scope',
     origin_node_group := 'left_dc',
@@ -110,28 +115,40 @@ these are:
 In rules for commit scopes, you can append these confirmation levels
 to the node group definition in parenthesis with `ON` as follows:
 
-* `ANY 1 (right_dc) ON remote_write`
-* `ALL (left_dc) ON remote_commit_flush` (default and may as well be
+* `ANY 2 (right_dc) ON replicated`
+* `ALL (left_dc) ON visible` (default and may as well be
   omitted)
-* `ALL (left_dc) ON remote_commit_async AND ANY 1 (right_dc) ON remote_write`
+* `ALL (left_dc) ON received AND ANY 1 (right_dc) ON durable`
 
 ## Reference
 
 ### Commit scope grammar
 
-For reference, the grammar for commit scopes is as follows:
+For reference, the grammar for commit scopes is composed as follows:
 
 ```
-commit_scope: confirmation
-              | confirmation AND commit_scope
+commit_scope:
+    confirmation [AND ...]
 
-confirmation: node_def (ON [received|replicated|durable|visible])
+confirmation:
+    node_def (ON [received|replicated|durable|visible])
 
-node_def:     ANY num (node_group [, ...])
-              | MAJORITY (node_group [, ...])
-              | ALL (node_group [, ...])
+node_def:
+    ANY num (node_group [, ...])
+    | MAJORITY (node_group [, ...])
+    | ALL (node_group [, ...])
 ```
 
+!!! Note
+    While the grammar for `synchronous_standby_names` and Commit
+    Scopes looks very similar, it is important to note that the former
+    does not account for the origin node, but the latter does.
+    Therefore, for example `synchronous_standby_names = 'ANY 1 (..)'`
+    is equivalent to a Commit Scope of `ANY 2 (...)`.  This choice
+    makes reasoning about majority easier and reflects that the origin
+    node also contributes to the durability and visibility of the
+    transaction.
+
 ### Adding a commit scope rule
 
 The function `bdr.add_commit_scope` creates a rule for the given
@@ -146,8 +163,10 @@ commit scopes that vary depending on the origin of the transaction.
 #### Synopsis
 
 ```sql
-bdr.add_commit_scope(commit_scope_name NAME, origin_node_group NAME,
-                     rule TEXT)
+bdr.add_commit_scope(
+    commit_scope_name NAME,
+    origin_node_group NAME,
+    rule TEXT)
 ```
 
 ### Changing a commit scope rule
@@ -158,8 +177,10 @@ commit scope, you can use the function `bdr.alter_commit_scope`.
 #### Synopsis
 
 ```sql
-bdr.alter_commit_scope(commit_scope_name NAME, origin_node_group NAME,
-                       rule TEXT)
+bdr.alter_commit_scope(
+    commit_scope_name NAME,
+    origin_node_group NAME,
+    rule TEXT)
 ```
 
 ### Removing a commit scope rule
@@ -172,5 +193,12 @@ commit scope.
 #### Synopsis
 
 ```sql
-bdr.remove_commit_scope(commit_scope_name NAME, origin_node_group NAME)
+bdr.remove_commit_scope(
+    commit_scope_name NAME,
+    origin_node_group NAME)
 ```
+
+!!! Note
+    Removing a commit scope that is still used as default by a node
+    group is not allowed
+