[create-pull-request] automated change

product_docs/docs/bdr/3.7/backup.mdx

@@ -20,7 +20,7 @@ Recovery (DR), such as in the following situations:
 
 ## Backup
 
-### `pg_dump`
+### pg_dump
 
 `pg_dump`, sometimes referred to as "logical backup", can be used
 normally with BDR.
@@ -232,6 +232,54 @@ of a single BDR node, optionally plus WAL archives:
 -   Add further BDR nodes with the standard procedure based on the
     `bdr.join_node_group()` function call.
 
+### pg_dump restore
+
+The restore procedure using pg_dump is somehow simpler (but not as consistent
+as phisycal backups because it only makes a snapshot of a given moment in time).
+The dump only takes personal data and not catalog data (BDR).
+
+Creating a new cluster from a dump needs only a new Postgresql instance where
+to restore normally the dump.
+The result is a plain postgres instance with all personal data.
+
+**No catalog changes are restored from the original BDR node.**
+You need to manually create the BDR cluster from ths instance.
+Create the BDR extension , create the node, create the bdr group, etc. and
+eventually join other nodes to this instance.
+
+There is only one caveat to keep in mind when restoring a BDR dump.
+BDR creates two policies on the `bdr.conflict_history table`. Postgresql normal
+behavior does not allow to tie policies to an extension so these will be dumped
+together with your data. These policies, unless removed from the dump, will drag
+also the BDR extension and grant some permissions.
+
+You need to manually remove those statements from the dump prior restoring it.
+
+The statements you need to delete from the dump are the following:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS bdr WITH SCHEMA pg_catalog;
+COMMENT ON EXTENSION bdr IS 'Bi-Directional Replication for PostgreSQL';
+CREATE POLICY conflict_filter ON bdr.conflict_history FOR SELECT USING (((( SELECT c.relowner
+            FROM pg_class c
+        WHERE (c.oid = conflict_history.reloid)) = ( SELECT pg_roles.oid
+            FROM pg_roles
+        WHERE (pg_roles.rolname = CURRENT_USER))) AND ( SELECT (NOT (c.relrowsecurity AND c.relforcerowsecurity))
+            FROM pg_class c
+        WHERE (c.oid = conflict_history.reloid))));
+ALTER TABLE bdr.conflict_history ENABLE ROW LEVEL SECURITY;
+CREATE POLICY conflict_read_all ON bdr.conflict_history FOR SELECT TO bdr_read_all_conflicts USING (true);
+REVOKE ALL ON TABLE bdr.conflict_history FROM postgres;
+REVOKE SELECT ON TABLE bdr.conflict_history FROM PUBLIC;
+GRANT ALL ON TABLE bdr.conflict_history TO bdr_superuser;
+GRANT SELECT ON TABLE bdr.conflict_history TO PUBLIC;
+```
+
+!!! Note
+    In the example, `postgres` is the initdb user, if you create the PostgreSQL
+    instance with a different user, then that user will be shown instead in the
+    dump, related to the `REVOKE` on `bdr.conflict_history` table.
+
 #### Cleanup BDR Metadata
 
 The cleaning of leftover BDR metadata is achieved as follows:

product_docs/docs/bdr/3.7/configuration.mdx

@@ -104,6 +104,44 @@ pglogical internally to implement the basic replication.
 -   `pglogical.max_writers_per_subscription` - Maximum number of writers
     per subscription (sets upper limit for the setting above).
 
+### `pglogical.min_worker_backoff_delay` and `pglogical.max_worker_backoff_delay`
+
+Rate limit BDR background worker launches by preventing a given worker
+from being relaunched more often than every
+`pglogical.min_worker_backoff_delay` milliseconds. On repeated errors, the back-off
+increases exponentially with added jitter up to maximum of
+`pglogical.max_worker_backoff_delay`.
+
+Time-unit suffixes are supported.
+
+!!! Note
+    This setting currently only affects receiver worker, which means it
+    primarily affects how fast a subscription will try to reconnect on error
+    or connection failure.
+
+The default for `pglogical.min_worker_backoff_delay` 1 second, for
+`pglogical.max_worker_backoff_delay` it is 1 minute.
+
+If the backoff delay setting is changed and the PostgreSQL configuration is
+reloaded then all current backoff waits will be reset. Additionally, the
+`pglogical.worker_task_reset_backoff_all()` function is provided to allow the
+administrator to force all backoff intervals to immediately expire.
+
+A tracking table in shared memory is maintained to remember the last launch
+time of each type of worker. This tracking table is not persistent; it is
+cleared by PostgreSQL restarts, including soft-restarts during crash recovery
+after an unclean backend exit.
+
+The view `pglogical.worker_tasks` may be used to inspect this state so the
+administrator can see any backoff rate-limiting currently in effect.
+
+For rate limiting purposes, workers are classified by "task". This key consists
+of the worker role, database oid, subscription id, subscription writer id,
+extension library name and function name, extension-supplied worker name, and
+the remote relation id for sync writers. `NULL` is used where a given
+classifier does not apply, e.g. manager workers don't have a subscription ID
+and receivers don't have a writer id.
+
 ## BDR Specific Settings
 
 There are also BDR specific configuration settings that can be set.

product_docs/docs/bdr/3.7/nodes.mdx

@@ -1311,6 +1311,10 @@ worker stopping depends on the value of `immediate`; if set to `true`, the
 workers will be stopped immediately; if set to `false`, they will be stopped at
 the `COMMIT` time.
 
+!!! Note
+    With the parameter `immediate` set to `true`, the stop will however wait
+    for the workers to finish current work.
+
 ## Node Management Commands
 
 BDR also provides a command line utility for adding nodes to the BDR group via

product_docs/docs/bdr/3.7/release-notes.mdx

@@ -5,6 +5,57 @@ originalFilePath: release-notes.md
 
 ---
 
+## BDR 3.7.16
+
+This is a maintenance release for BDR 3.7 which includes minor
+improvements as well as fixes for issues identified in previous
+versions.
+
+Check also release notes for pglogical 3.7.16 for resolved issues
+which affect BDR as well.
+
+### Resolved Issues
+
+-   Make ALTER TABLE lock the underlying relation only once (RT80204)  
+    This avoids the ALTER TABLE operation falling behind in the queue
+    when it released the lock in between internal operations. With this
+    fix, concurrent transactions trying to acquire the same lock after
+    the ALTER TABLE command will properly wait for the ALTER TABLE to
+    finish.
+
+-   Show a proper wait event for CAMO / Eager confirmation waits (BDR-1899, RT75900)  
+    Show correct "BDR Prepare Phase"/"BDR Commit Phase" in `bdr.stat_activity`
+    instead of the default “unknown wait event”.
+
+-   Correct `bdr.monitor_local_replslots` for down nodes (BDR-2080)  
+    This function mistakenly returned an okay result for down nodes
+    before.
+
+-   Reduce log for bdr.run_on_nodes (BDR-2153, RT80973)  
+    Don't log when setting `bdr.ddl_replication` to off if it's
+    done with the "run_on_nodes" variants of function. This eliminates
+    the flood of logs for monitoring functions.
+
+-   Correct an SDW decoder restart edge case (BDR-2109)  
+    Internal testing revealed a possible error during WAL decoder
+    recovery about mismatch between confirmed_flush LSN of WAL decoder
+    slot also stating: "some LCR segments might be missing". This could
+    happen before in case the WAL decoder exited immediately after
+    processing a "Standby" WAL record other than "RUNNING_XACTS" and
+    would lead to a halt of replication with the decoder processes
+    continuing to restart.
+
+### Improvements
+
+-   Use 64 bits for calculating lag size in bytes (BDR-2215)
+
+### Upgrades
+
+This release supports upgrading from the following versions of BDR:
+
+-   3.7.9 and higher
+-   3.6.29 and higher
+
 ## BDR 3.7.15
 
 This is a maintenance release for BDR 3.7 which includes minor
@@ -78,6 +129,13 @@ which affect BDR as well.
     requests or time consuming consensus requests, for example during join of a
     new node.
 
+### Upgrades
+
+This release supports upgrading from the following versions of BDR:
+
+-   3.7.9 and higher
+-   3.6.29 and higher
+
 ## BDR 3.7.14
 
 This is a maintenance release for BDR 3.7 which includes minor

product_docs/docs/bdr/3.7/repsets.mdx

@@ -461,16 +461,15 @@ Use the following SQL to show those replication sets that the
 current node publishes and subscribes from:
 
 ```sql
-SELECT s.node_id,
-        s.node_name,
+ SELECT node_id,
+        node_name,
         COALESCE(
-                i.pub_repsets, s.pub_repsets
+                pub_repsets, pub_repsets
         ) AS pub_repsets,
         COALESCE(
-                i.sub_repsets, s.sub_repsets
+                sub_repsets, sub_repsets
         ) AS sub_repsets
-FROM bdr.local_node_summary s
-INNER JOIN bdr.node_local_info i ON i.node_id = s.node_id;
+   FROM bdr.local_node_summary;
 ```
 
 This produces output like this:
@@ -490,25 +489,24 @@ the following query:
 WITH node_repsets AS (
   SELECT jsonb_array_elements(
     bdr.run_on_all_nodes($$
-        SELECT s.node_id,
-        s.node_name,
-        COALESCE(
-                i.pub_repsets, s.pub_repsets
-        ) AS pub_repsets,
-        COALESCE(
-                i.sub_repsets, s.sub_repsets
-        ) AS sub_repsets
-		FROM bdr.local_node_summary s
-		INNER JOIN bdr.node_local_info i
-		ON i.node_id = s.node_id;
+        SELECT
+          node_id,
+          node_name,
+          COALESCE(
+                pub_repsets, pub_repsets
+          ) AS pub_repsets,
+          COALESCE(
+                sub_repsets, sub_repsets
+          ) AS sub_repsets
+		FROM bdr.local_node_summary;
     $$)::jsonb
   ) AS j
 )
 SELECT j->'response'->'command_tuples'->0->>'node_id' AS node_id,
        j->'response'->'command_tuples'->0->>'node_name' AS node_name,
        j->'response'->'command_tuples'->0->>'pub_repsets' AS pub_repsets,
        j->'response'->'command_tuples'->0->>'sub_repsets' AS sub_repsets
-FROM node_repsets;;
+FROM node_repsets;
 ```
 
 This will show, for example: