Merge pull request #5338 from EnterpriseDB/release/2024-03-05a

Release/2024-03-05a
EnterpriseDB · Mar 5, 2024 · 6d18c27 · 6d18c27 · github-actions · Mar 5, 2024
2 parents 3361454 + c98317e
commit 6d18c27
Show file tree

Hide file tree

Showing 16 changed files with 483 additions and 108 deletions.
diff --git a/product_docs/docs/pgd/4/rel_notes/index.mdx b/product_docs/docs/pgd/4/rel_notes/index.mdx
@@ -2,6 +2,7 @@
 title: "EDB Postgres Distributed Release notes"
 navTitle: "Release notes"
 navigation:
+- pgd_4.3.4_rel_notes
 - pgd_4.3.3_rel_notes
 - pgd_4.3.2+p1_rel_notes
 - pgd_4.3.2_rel_notes
@@ -26,25 +27,26 @@ redirects:
 
 The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 4, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature.
 
-| Release Date | EDB Postgres Distributed     | BDR   | HARP  |  CLI  | TPAexec                                                                          |
-| ------------ | ---------------------------- | ----- | ----- | ----- | -------------------------------------------------------------------------------- |
-| 14 Nov 2023 | [4.3.3](pgd_4.3.3_rel_notes)| 4.3.3 | 2.3.2 | 1.1.2 | [23.24](/tpa/latest/rel_notes/tpa_23.24_rel_notes)   |
-| 17 Oct 2023 | [4.3.2+p1](pgd_4.3.2+p1_rel_notes)| 4.3.2 | 2.3.2 | 1.1.1 | [23.20](/tpa/latest/rel_notes/tpa_23.20_rel_notes)   |
-| 31 Aug 2023 | [4.3.2 ](pgd_4.3.2_rel_notes)| 4.3.2 | 2.3.1 | 1.1.1 | [23.20](/tpa/latest/rel_notes/tpa_23.20_rel_notes)   |
-| 27 Jul 2023 | [4.3.1+p2 ](pgd_4.3.1+p2_rel_notes)| 4.3.1 | 2.3.1 | 1.1.1 | [23.19](/tpa/latest/rel_notes/tpa_23.19_rel_notes)   |
-| 12 Jul 2023  | [4.3.1+p1 ](pgd_4.3.1+p1_rel_notes)| 4.3.1 | 2.3.0 | 1.1.1 | [23.19](/tpa/latest/rel_notes/tpa_23.19_rel_notes)   |
-| 17 May 2023 | [4.3.1](pgd_4.3.1_rel_notes) | 4.3.1 | 2.2.3 | 1.1.1 | [23.17](/tpa/latest/rel_notes/tpa_23.17_rel_notes)   |
-| 30 Mar 2023 | [4.3.0+p1](pgd_4.3.0+p1_rel_notes) | 4.3.0 | 2.2.2 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239)   |
-| 14 Feb 2023 | [4.3.0](pgd_4.3.0_rel_notes) | 4.3.0 | 2.2.1 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239)   |
-| 14 Dec 2022 | [4.2.2](pgd_4.2.2_rel_notes) | 4.2.2 | 2.2.1 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239)   |
-| 16 Nov 2022 | [4.2.1](pgd_4.2.1_rel_notes) | 4.2.1 | 2.2.1 | 1.1.0 | [23.7](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-237)   |
-| 22 Aug 2022 | [4.2.0](pgd_4.2.0_rel_notes) | 4.2.0 | 2.2.0 | 1.1.0 | [23.5](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-235)   |
-| 21 Jun 2022 | [4.1.1](pgd_4.1.1_rel_notes) | 4.1.1 | 2.1.1 | 1.0.0 | [23.2](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-232)   |
-| 17 May 2022 | [4.1.0](pgd_4.1.0_rel_notes) | 4.1.0 | 2.1.0 | 1.0.0 | [23.1](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-231)   |
-| 31 Mar 2022 | [4.0.3](pgd_4.0.3_rel_notes) | -     | 2.0.3 | -     | 22.10 |
-| 24 Feb 2022 | [4.0.2](pgd_4.0.2_rel_notes) | 4.0.2 | 2.0.2 | -     | 22.9   |
-| 31 Jan 2022 | [4.0.1](pgd_4.0.1_rel_notes) | 4.0.1 | 2.0.1 | -     | 22.6  |
-| 01 Dec 2021 | [4.0.0](pgd_4.0.0_rel_notes) | 4.0.0 | 2.0.0 | -     | 21.9  |
+| Release Date | EDB Postgres Distributed            | BDR   | HARP  | CLI   | TPAexec                                                      |
+|--------------|-------------------------------------|-------|-------|-------|--------------------------------------------------------------|
+| 05 Mar 2024  | [4.3.4](pgd_4.3.4_rel_notes)        | 4.3.4 | 2.4   | 1.1.2 | [23.29](tpa/latest/rel_notes/tpa_23.29_rel_notes/)           |
+| 14 Nov 2023  | [4.3.3](pgd_4.3.3_rel_notes)        | 4.3.3 | 2.3.2 | 1.1.2 | [23.24](/tpa/latest/rel_notes/tpa_23.24_rel_notes)           |
+| 17 Oct 2023  | [4.3.2+p1](pgd_4.3.2+p1_rel_notes)  | 4.3.2 | 2.3.2 | 1.1.1 | [23.20](/tpa/latest/rel_notes/tpa_23.20_rel_notes)           |
+| 31 Aug 2023  | [4.3.2 ](pgd_4.3.2_rel_notes)       | 4.3.2 | 2.3.1 | 1.1.1 | [23.20](/tpa/latest/rel_notes/tpa_23.20_rel_notes)           |
+| 27 Jul 2023  | [4.3.1+p2 ](pgd_4.3.1+p2_rel_notes) | 4.3.1 | 2.3.1 | 1.1.1 | [23.19](/tpa/latest/rel_notes/tpa_23.19_rel_notes)           |
+| 12 Jul 2023  | [4.3.1+p1 ](pgd_4.3.1+p1_rel_notes) | 4.3.1 | 2.3.0 | 1.1.1 | [23.19](/tpa/latest/rel_notes/tpa_23.19_rel_notes)           |
+| 17 May 2023  | [4.3.1](pgd_4.3.1_rel_notes)        | 4.3.1 | 2.2.3 | 1.1.1 | [23.17](/tpa/latest/rel_notes/tpa_23.17_rel_notes)           |
+| 30 Mar 2023  | [4.3.0+p1](pgd_4.3.0+p1_rel_notes)  | 4.3.0 | 2.2.2 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239) |
+| 14 Feb 2023  | [4.3.0](pgd_4.3.0_rel_notes)        | 4.3.0 | 2.2.1 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239) |
+| 14 Dec 2022  | [4.2.2](pgd_4.2.2_rel_notes)        | 4.2.2 | 2.2.1 | 1.1.0 | [23.9](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-239) |
+| 16 Nov 2022  | [4.2.1](pgd_4.2.1_rel_notes)        | 4.2.1 | 2.2.1 | 1.1.0 | [23.7](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-237) |
+| 22 Aug 2022  | [4.2.0](pgd_4.2.0_rel_notes)        | 4.2.0 | 2.2.0 | 1.1.0 | [23.5](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-235) |
+| 21 Jun 2022  | [4.1.1](pgd_4.1.1_rel_notes)        | 4.1.1 | 2.1.1 | 1.0.0 | [23.2](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-232) |
+| 17 May 2022  | [4.1.0](pgd_4.1.0_rel_notes)        | 4.1.0 | 2.1.0 | 1.0.0 | [23.1](/tpa/latest/rel_notes/tpa_23.1-11_rel_notes/#tpa-231) |
+| 31 Mar 2022  | [4.0.3](pgd_4.0.3_rel_notes)        | -     | 2.0.3 | -     | 22.10                                                        |
+| 24 Feb 2022  | [4.0.2](pgd_4.0.2_rel_notes)        | 4.0.2 | 2.0.2 | -     | 22.9                                                         |
+| 31 Jan 2022  | [4.0.1](pgd_4.0.1_rel_notes)        | 4.0.1 | 2.0.1 | -     | 22.6                                                         |
+| 01 Dec 2021  | [4.0.0](pgd_4.0.0_rel_notes)        | 4.0.0 | 2.0.0 | -     | 21.9                                                         |
 
 
 !!! Note About version numbers

diff --git a/product_docs/docs/pgd/4/rel_notes/pgd_4.3.4_rel_notes.mdx b/product_docs/docs/pgd/4/rel_notes/pgd_4.3.4_rel_notes.mdx
@@ -0,0 +1,31 @@
+---
+title: "Release notes for EDB Postgres Distributed version 4.3.4"
+navTitle: "Version 4.3.4"
+redirects:
+  - /pgd/latest/bdr/release_notes/bdr4.3.4_rel_notes/
+---
+
+Released: 5 Mar 2024
+
+EDB Postgres Distributed version 4.3.4 is a patch release of EDB Postgres Distributed 4, which includes bug fixes for issues identified in previous versions.
+
+!!! Note
+This version is required for EDB Postgres Advanced Server versions 12.15, 13.11, 14.10, 15.5 and later.
+!!!
+
+| Component | Version | Type         | Description                                                                                 |
+|-----------|---------|--------------|---------------------------------------------------------------------------------------------|
+| BDR       | 4.3.4   | Bug&nbsp;fix | Change default value of bdr.writers_per_subscription to 1.                                  |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Run ANALYZE on the internal raft tables, RT97735.                                           |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Fix segfault in I2PC concurrent abort case, RT93962.                                        |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Avoid bypassing other extensions in BdrProcessUtility when processing COPY..TO, RT99345.    |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Ensure that consensus connection are handled correctly, RT97649.                            |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Fix selected memory leaks, RT99231/RT95314.                                                 |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Add default_table_access_method to replicated GUCs.                                         |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Add missing GUCs to DDL replication GUC list.                                               |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Improve local node connection failure logging.                                              |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Rework raft snapshot group restore algorithm.                                               |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Apply node group change to subscription in raft snapshot restore.                           |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Fix commit queue cleanup and flush queueing up for prepared transactions in parallel apply. |
+| BDR       | 4.3.4   | Bug&nbsp;fix | Increase default bdr.raft_keep_min_entries to 1000 for 100.                                 |
+
diff --git a/product_docs/docs/pgd/5/consistency/eager.mdx b/product_docs/docs/pgd/5/consistency/eager.mdx
@@ -50,15 +50,33 @@ In case of an origin node failure, the remaining nodes eventually (after at leas
 
 ## Effects of Eager Replication in general
 
-#### Increased commit latency
+#### Increased abort rate
 
-Adding a synchronization step means more communication between the nodes, resulting in more latency at commit time. Eager All-Node Replication adds roughly two network roundtrips (to the furthest peer node in the worst case). Logical standby nodes and nodes still in the process of joining or catching up aren't included but eventually receive changes.
+With single-node Postgres, or even with PGD in its default asynchronous
+replication mode, errors at `COMMIT` time are rare. The added synchronization 
+step due to the use of a commit scope using eager
+for conflict resolution also adds a source of errors. Applications need to be
+prepared to properly handle such errors (usually by applying a retry loop).
 
-Before a peer node can confirm its local preparation of the transaction, it also needs to apply it locally. This further adds to the commit latency, depending on the size of the transaction. This setting is independent of the `synchronous_commit` setting.
+The rate of aborts depends solely on the workload. Large transactions changing many rows are much more likely to conflict with other concurrent transactions.
 
-#### Increased abort rate
+## Effects of MAJORITY and ALL node replication in general
 
-With single-node Postgres, or even with PGD in its default asynchronous replication mode, errors at `COMMIT` time are rare. The added synchronization step adds a source of errors, so applications need to
-be prepared to properly handle such errors (usually by applying a retry loop).
+### Increased commit latency
+
+Adding a synchronization step due to the use of a commit scope means more
+communication between the nodes, resulting in more latency at commit time. When
+ALL is used in the commit scope, this also means that the availability of the
+system is reduced, since any node going down causes transactions to fail. 
+
+If one or more nodes are lagging behind, the round-trip delay in getting
+confirmations can be large, causing high latencies. ALL or MAJORITY node replication adds
+roughly two network round trips (to the furthest peer node in the worst case).
+Logical standby nodes and nodes still in the process of joining or catching up
+aren't included but eventually receive changes.
+
+Before a peer node can confirm its local preparation of the transaction, it also
+needs to apply it locally. This further adds to the commit latency, depending on
+the size of the transaction. This setting is independent of the
+`synchronous_commit` setting.
 
-The rate of aborts depends solely on the workload. Large transactions changing many rows are much more likely to conflict with other concurrent transactions.
diff --git a/product_docs/docs/pgd/5/durability/camo.mdx b/product_docs/docs/pgd/5/durability/camo.mdx
@@ -45,6 +45,15 @@ To use CAMO, an application must issue an explicit `COMMIT` message as a separat
 
 Configuration of CAMO happens through [commit scopes](commit-scopes).
 
+## Confirmation
+
+   Confirmation&nbsp;Level    | CAMO Handling
+-------------------------|-------------------------------
+ `received`              | Not applicable, only uses the default `VISIBLE`.
+ `replicated`            | Not applicable, only uses the default `VISIBLE`.
+ `durable`               | Not applicable, only uses the default `VISIBLE`.
+ `visible` (default)     | Confirms the transaction after all of its changes are flushed to disk and it's visible to concurrent transactions.
+
 ## Limitations
 
 See the CAMO section of the [Limitations](limitations#camo) section.

diff --git a/product_docs/docs/pgd/5/durability/commit-scope-rules.mdx b/product_docs/docs/pgd/5/durability/commit-scope-rules.mdx
@@ -30,11 +30,11 @@ ANY 2 (group) ON visible GROUP COMMIT
 
 The visible setting means the nodes are able to confirm once the all the transaction's changes are flushed to disk and visible to other transactions.
 
-The last part of this operation is the commit scope kind, which here is `GROUP COMMIT`, a synchronous two-phase commit which will be confirmed when any two nodes in the named group confirm they have flushed and made visible the transactions changes.
+The last part of this operation is the commit scope kind, which here is `GROUP COMMIT`, a synchronous two-phase commit which will be confirmed when any two nodes in the named group confirm they have flushed and made visible the transactions changes. 
 
 ## The commit scope group
 
-There are three kinds of commit scope group, `ANY`, `ALL` and `MAJORITY`. They are all followed by a parenthesed list of one or more groups, which combine to make a pool of nodes that this operation will apply to. This list can be preceded by `NOT` which inverts to pool to all other groups apart from those in the list.
+There are three kinds of commit scope group, `ANY`, `ALL` and `MAJORITY`. They are all followed by a parenthesized list of one or more groups, which combine to make a pool of nodes that this operation will apply to. This list can be preceded by `NOT` which inverts to pool to all other groups apart from those in the list. Witness nodes are not eligible to be included in this pool as they do not replicate data.
 
 - `ANY n` &mdash; is followed by an integer value, "n". It translates to any "n" nodes in the listed groups nodes.
 - `ALL` &mdash; is followed by the groups and translates to all nodes in the listed groups nodes.

diff --git a/product_docs/docs/pgd/5/durability/commit-scopes.mdx b/product_docs/docs/pgd/5/durability/commit-scopes.mdx
@@ -23,11 +23,11 @@ Finally there is the rule which defines what kind of commit scope or combination
 So if a commit scope has a rule that reads:
 
     origin_node_group := 'example_bdr_group',
-    rule := 'ANY 2 (example_bdr_group) GROUP COMMIT',
+    rule := 'MAJORITY (example_bdr_group) GROUP COMMIT',
 
-Then, the rule is applies when any node in the `example_bdr_group` makes a change. 
+Then, the rule is applied when any node in the `example_bdr_group` issues a transaction. 
 
-The rule itself specifies how many nodes of a specified group will need to confirm the change - `ANY 2 (example_bdr_group)` - followed by the commit scope kind itself - `GROUP COMMIT`. This translates to requiring that any two nodes in `example_bdr_group` must confirm the change before the change can be considered as comitted.
+The rule itself specifies how many nodes of a specified group will need to confirm the change - `MAJORITY (example_bdr_group)` - followed by the commit scope kind itself - `GROUP COMMIT`. This translates to requiring that any two nodes in `example_bdr_group` must confirm the change before the change can be considered as comitted.
 
 ## How a commit scope is selected
 
@@ -39,6 +39,8 @@ If not specified, the system will search for a default commit scope. Default com
 
 If no default_commit_scope is found then the node's GUC, bdr.commit_scope is used. And if that isn't set or is set to `local` then no commit scope applies and PGD's async replication is used.
 
+A commit scope will not be used if it is not local and the node where the commit is being run on is not directly or indirectly related to the origin_node_group.
+
 ## Creating a Commit Scope
 
 Use `bdr.add_commit_scope` to add our example rule to a commit scope. For example:
@@ -47,12 +49,12 @@ Use `bdr.add_commit_scope` to add our example rule to a commit scope. For exampl
 SELECT bdr.add_commit_scope(
     commit_scope_name := 'example_scope',
     origin_node_group := 'example_bdr_group',
-    rule := 'ANY 2 (example_bdr_group) GROUP COMMIT',
+    rule := 'MAJORITY (example_bdr_group) GROUP COMMIT',
     wait_for_ready := true
 );
 ```
 
-This will add the rule `ANY 2 (example_bdr_group) GROUP COMMIT` for any transaction originating from the `example_bdr_group` to a scope called `example_scope`. 
+This will add the rule `MAJORITY (example_bdr_group) GROUP COMMIT` for any transaction originating from the `example_bdr_group` to a scope called `example_scope`. 
 
 If no rules previously existed in `example_scope`, then adding this rule would make the scope exist.