Merge branch 'develop' into release/2022-05-19a

product_docs/docs/pglogical/3.7/configuration.mdx

@@ -127,6 +127,12 @@ Collecting statistics requires additional CPU resources on the subscriber.
 
 The default is off.
 
+### `pglogical.track_apply_lock_timing`
+
+This tracks lock timing when tracking statistics for relations.
+
+The default is off.
+
 ### `pglogical.temp_directory`
 
 This defines system path for where to put temporary files needed for schema
@@ -256,16 +262,23 @@ should be enough. The default is 32kB and the maximum allowed size is 1MB.
 While any storage size specifier can be used to set the GUC, the default is
 kB.
 
-### `pglogical.min_worker_backoff_delay`
+### `pglogical.min_worker_backoff_delay` and `pglogical.max_worker_backoff_delay`
 
 Rate limit pglogical background worker launches by preventing a given worker
 from being relaunched more often than every
-`pglogical.min_worker_backoff_delay` milliseconds. Time-unit suffixes are
-supported.
+`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 is 0, meaning no rate limit. The delay is a time limit applied from
-launch-to-launch, so a value of `'500ms'` would limit all types of workers to
-at most 2 (re)launches per second.
+The default for `pglogical.min_worker_backoff_delay` is 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

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

@@ -5,17 +5,50 @@ originalFilePath: release-notes.md
 
 ---
 
+## pglogical 3.7.16
+
+This is a maintenance release for pglogical 3.7 which includes minor
+improvements as well as fixes for issues identified previously.
+
+### Resolved Issues
+
+-   Keep the `lock_timeout` as configured on non-CAMO-partner BDR nodes (BDR-1916)  
+    A CAMO partner uses a low `lock_timeout` when applying transactions
+    from its origin node.  This was inadvertently done for all BDR nodes
+    rather than just the CAMO partner, which may have led to spurious
+    `lock_timeout` errors on pglogical writer processes on normal BDR
+    nodes.
+
+-   Prevent walsender processes spinning when facing lagging standby slots (RT80295, RT78290)  
+    Correct signaling to reset a latch so that a walsender process does
+    consume 100% of a CPU in case one of the standby slots is lagging
+    behind.
+
+-   Provide a proper error when attempting to use `pglogical.use_spi` (RT76368)
+
+-   Reduce log information when switching between writer processes (BDR-2196)
+
+-   Eliminate a memory leak when replicating partitioned tables (RT80981, BDR-2194)
+
+### Upgrades
+
+This release supports upgrading from following versions of pglogical:
+
+-   3.7.9 and higher
+-   3.6.29 and higher
+-   2.4.0 and 2.4.1
+
 ## pglogical 3.7.15
 
 This is a maintenance release for pglogical 3.7 which includes minor
 improvements as well as fixes for issues identified previously.
 
 ### Improvements
 
--   Add `bdr.max_worker_backoff_delay` (BDR-1767)  
+-   Add `pglogical.max_worker_backoff_delay` (BDR-1767)
     This changes the handling of the backoff delay to exponentially
-    increase from `bdr.min_worker_backoff_delay` to
-    `bdr.max_worker_backoff_delay` in presence of repeated errors.  This
+    increase from `pglogical.min_worker_backoff_delay` to
+    `pglogical.max_worker_backoff_delay` in presence of repeated errors.  This
     reduces log spam and in some cases also prevents unnecessary
     connection attempts.
 
@@ -29,15 +62,23 @@ improvements as well as fixes for issues identified previously.
     The `wal_receiver_timeout` has not been triggered correctly due to a regression
     in BDR 3.7 and 4.0.
 
--   Limit the `bdr.standby_slot_names` check when reporting flush position only to
+-   Limit the `pglogical.standby_slot_names` check when reporting flush position only to
     physical slots (RT77985, RT78290)  
     Otherwise flush progress is not reported in presence of disconnected nodes when
-    using `bdr.standby_slot_names`.
+    using `pglogical.standby_slot_names`.
 
 -   Confirm LSN of LCR slot progress records when recovering LCR segments (BDR-1264)
 
 -   Fix replication of data types created during bootstrap (BDR-1784)
 
+### Upgrades
+
+This release supports upgrading from following versions of pglogical:
+
+-   3.7.9 and higher
+-   3.6.29 and higher
+-   2.4.0 and 2.4.1
+
 ## pglogical 3.7.14
 
 This is a maintenance release for pglogical 3.7 which includes minor

product_docs/docs/pglogical/3.7/subscriptions/index.mdx

@@ -223,9 +223,8 @@ alternately choose your own replication slot name instead of using
      pglogical.writers_per_subscription. Valid values are either -1 or a
      positive integer.
 -   `writer` - which writer to use for writing the data from the replication
-    stream. Available writers currently are `local`, `HeapWriter` and
-    `SPIWriter`; the local is an alias that automatically selects either
-    `HeapWriter` or `SPIWriter` based on the version of PostgreSQL being used.
+    stream.  Only `HeapWriter` is supported in this version of PGLogical.
+    `local` is an alias for backwards compatibility.
 -   `writer_options` - writer-specific options as an array of keys and values
 
 ### `pglogical_create_subscriber`