Merge pull request #2238 from EnterpriseDB/release/2022-01-18a

Release: 2022-01-18a
EnterpriseDB · Jan 19, 2022 · 7f29438 · 7f29438
2 parents 1df7e26 + 48ca6e8
commit 7f29438
Show file tree

Hide file tree

Showing 23 changed files with 375 additions and 200 deletions.
diff --git a/product_docs/docs/bdr/4.0/appusage.mdx b/product_docs/docs/bdr/4.0/appusage.mdx
@@ -361,9 +361,9 @@ application.
 
 ### pgbench with CAMO/Failover options
 
-pgbench has been extended to allow users to run failover tests while
-using CAMO or regular BDR deployments. The following new options have
-been added:
+In EDB Postgres Extended, the pgbench has been extended to allow users to
+run failover tests while using CAMO or regular BDR deployments. The following
+new options have been added:
 
 ```
 -m, --mode=regular|camo|failover
@@ -624,9 +624,9 @@ BDR cannot currently perform conflict resolution where the PRIMARY KEY is change
 by an UPDATE operation. It is permissible to update the primary key, but you must
 ensure that no conflict with existing values is possible.
 
-When running on EDB Postgres Extended, BDR provides the following configuration
-parameter to assess how frequently the primary key/replica identity of any table
-is being subjected to update operations.
+BDR provides the following configuration parameter to assess how frequently
+the primary key/replica identity of any table is being subjected to update
+operations.
 
 Note that these configuration parameters must only be used for assessment only.
 They can be used on a single node BDR instance, but must not be used on a production
@@ -659,8 +659,8 @@ Because BDR writer processes operate much like normal user sessions, they are su
 the usual rules around row and table locking. This can sometimes lead to BDR writer
 processes waiting on locks held by user transactions, or even by each other.
 
-When running on EDB Postgres Extended, BDR provides the following
-configuration parameter to assess if the application is taking explicit locks.
+BDR provides the following configuration parameter to assess if the application
+is taking explicit locks.
 
 ```sql
 bdr.assess_lock_statement = IGNORE (default) | LOG | WARNING | ERROR

diff --git a/product_docs/docs/bdr/4.0/camo_clients.mdx b/product_docs/docs/bdr/4.0/camo_clients.mdx
@@ -1,5 +1,5 @@
 ---
-navTitle: 'Appendix F: CAMO Reference Clients'
+navTitle: 'Appendix E: CAMO Reference Clients'
 title: CAMO Clients
 originalFilePath: camo_clients.md
 

diff --git a/product_docs/docs/bdr/4.0/catalogs.mdx b/product_docs/docs/bdr/4.0/catalogs.mdx
@@ -1043,17 +1043,22 @@ Specific information about BDR writer processes.
 
 #### `bdr.writers` Columns
 
-| Name                  | Type        | Description                                                       |
-| --------------------- | ----------- | ----------------------------------------------------------------- |
-| sub_name              | name        | Name of the subscription                                          |
-| pid                   | int         | Process Id of the worker process                                  |
-| syncing_rel           | int         | Oid of the relation being synchronized (if any)                   |
-| streaming_allowed     | text        | Can this writer be target of direct to writer streaming           |
-| is_streaming          | bool        | Is there transaction being streamed to this writer                |
-| remote_xid            | xid         | Remote transaction id of the transaction being processed (if any) |
-| remote_commit_lsn     | pg_lsn      | LSN of last commit processed                                      |
-| commit_queue_position | int         | Position in the internal commit queue                             |
-| commit_timestamp      | timestamptz | Timestamp of last commit processed                                |
+| Name                  | Type        | Description                                                        |
+| --------------------- | ----------- | ------------------------------------------------------------------ |
+| sub_name              | name        | Name of the subscription                                           |
+| pid                   | int         | Process Id of the worker process                                   |
+| syncing_rel           | int         | Oid of the relation being synchronized (if any)                    |
+| streaming_allowed     | text        | Can this writer be target of direct to writer streaming            |
+| is_streaming          | bool        | Is there transaction being streamed to this writer                 |
+| remote_xid            | xid         | Remote transaction id of the transaction being processed (if any)  |
+| remote_commit_lsn     | pg_lsn      | LSN of last commit processed                                       |
+| commit_queue_position | int         | Position in the internal commit queue                              |
+| commit_timestamp      | timestamptz | Timestamp of last commit processed                                 |
+| nxacts                | bigint      | Number of transactions processed by this writer                    |
+| ncommits              | bigint      | Number of transactions committed by this writer                    |
+| naborts               | bigint      | Number of transactions aborted by this writer                      |
+| nstream_file          | bigint      | Number of streamed-to-file transactions processed by this writer   |
+| nstream_writer        | bigint      | Number of streamed-to-writer transactions processed by this writer |
 
 ### `bdr.worker_tasks`
 

diff --git a/product_docs/docs/bdr/4.0/column-level-conflicts.mdx b/product_docs/docs/bdr/4.0/column-level-conflicts.mdx
@@ -60,10 +60,6 @@ Column-level conflict resolution requires the table to have `REPLICA
 IDENTITY FULL`. The `bdr.alter_table_conflict_detection` function does check
 that, and will fail with an error otherwise.
 
-!!! Note
-    This feature is currently only available on EDB Postgres Extended and
-    EDB Postgres Advanced.
-
 ## Enabling and Disabling Column-Level Conflict Resolution
 
 The Column-Level Conflict Resolution is managed by the

diff --git a/product_docs/docs/bdr/4.0/configuration.mdx b/product_docs/docs/bdr/4.0/configuration.mdx
@@ -68,23 +68,6 @@ Applications may also wish to set these parameters. Please see chapter on
     in a similar way to [physical replication](https://www.postgresql.org/docs/11/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT).
 -   `synchronous_standby_names` - same as above
 
-## EDB PG Extended and EDB PG Advanced Settings for BDR
-
-The following Postgres settings need to be considered for commit at
-most once (CAMO), a feature that is only available for BDR in
-combination with PG Extended.  Some of these are only available in
-PG Extended; others already exist in the community version, but only
-become relevant with BDR in combination with CAMO.
-
--   `synchronous_replication_availability` - Can optionally be `async`
-    for increased availability by allowing a node to continue and
-    commit after its CAMO partner got disconnected.  Under the default
-    value of `wait`, the node will wait indefinitely, and proceed to
-    commit only after the CAMO partner reconnects and sends
-    confirmation.
--   `snapshot_timestamp` - Turns on the usage of
-    [timestamp-based snapshots](tssnapshots) and sets the timestamp to use.
-
 ## BDR Specific Settings
 
 There are also BDR specific configuration settings that can be set.
@@ -395,7 +378,6 @@ and receivers don't have a writer id.
     local two-phase commit or CAMO transaction, and will prevent all
     Eager transactions on the cluster.
     May only be set at Postgres server start.
-    (EDB Postgres Extended)
 
 ### Eager Replication
 
@@ -407,9 +389,6 @@ and receivers don't have a writer id.
     in their commit phase, as a limit for how long to wait for the CAMO
     partner.
 
-!!! Note
-    This is only available on EDB Postgres Extended.
-
 ### Commit at Most Once
 
 -   `bdr.enable_camo` - Used to enable and control the CAMO feature.
@@ -430,9 +409,12 @@ and receivers don't have a writer id.
     carried out in the database for which CAMO properties cannot be
     guaranteed. This is enabled by default. Well-informed users can choose
     to disable this to reduce the amount of warnings going into their logs.
-
-!!! Note
-    This is only available on EDB Postgres Extended.
+-   `synchronous_replication_availability` - Can optionally be `async`
+    for increased availability by allowing a node to continue and
+    commit after its CAMO partner got disconnected.  Under the default
+    value of `wait`, the node will wait indefinitely, and proceed to
+    commit only after the CAMO partner reconnects and sends
+    confirmation.
 
 ### Transaction streaming
 
@@ -441,16 +423,15 @@ and receivers don't have a writer id.
     Defaults to `auto`.  If set to `off`, the subscriber will not request
     transaction streaming.  If set to one of the other permissible values, the
     subscriber will request transaction streaming and the publisher will provide
-    this if it supports them (support is available from BDR 4.0 with PostgreSQL
-    14, EDB Postgres Extended 13 and EPAS 14) and configured at group level. For
+    this if it supports them and configured at group level. For
     more details, see [Transaction Streaming](transaction-streaming).
 
 ### Timestamp-based Snapshots
 
+-   `snapshot_timestamp` - Turns on the usage of
+    [timestamp-based snapshots](tssnapshots) and sets the timestamp to use.
 -   `bdr.timestamp_snapshot_keep` - For how long to keep valid snapshots for the
     timestamp-based snapshot usage (default 0, meaning do not keep past snapshots).
-    Also see `snapshot_timestamp` above.
-    (EDB Postgres Extended)
 
 ### Monitoring and Logging
 
@@ -510,10 +491,8 @@ and receivers don't have a writer id.
     of apply rates and catchup intervals for peer nodes.  This information can
     be used by protocols like CAMO to estimate the readiness of a
     peer node. This parameter is enabled by default.
-    (EDB Postgres Extended)
 -   `bdr.lag_tracker_apply_rate_weight` - We monitor how far behind peer nodes
     are in terms of applying WAL from the local node, and calculate a moving
     average of the apply rates for the lag tracking. This parameter specifies
     how much contribution newer calculated values have in this moving average
     calculation. Default value is 0.1.
-    (EDB Postgres Extended)
diff --git a/product_docs/docs/bdr/4.0/conflicts.mdx b/product_docs/docs/bdr/4.0/conflicts.mdx
@@ -708,13 +708,11 @@ as is normally the case with BDR AlwaysOn architecture.
 
 !!! Warning
     The additional WAL logging of TOAST is done using the `BEFORE UPDATE`
-    trigger. This trigger must be sorted alphabetically
+    trigger on standard PostgreSQL. This trigger must be sorted alphabetically
     last (based on trigger name) among all `BEFORE UPDATE` triggers on the
     table. It's prefixed with `zzzz_bdr_` to make this easier, but make sure
     you don't create any trigger with name that would sort after it, otherwise
     the protection against the concurrency issues will not be present.
-    This trigger is not created or used when using BDR with EDB Postgres
-    Extended.
 
 For the `insert_or_error` conflict resolution, the use of
 `REPLICA IDENTITY FULL` is however still required.
@@ -813,9 +811,9 @@ frozen rows that they update. Inserts and Deletes are not affected by this situa
 Users are advised to not leave down nodes for extended outages,
 as discussed in [Node Restart and Down Node Recovery](nodes).
 
-On EDB Postgres Extended, BDR will automatically hold back the freezing of
-rows while a node is down to handle this situation gracefully without the need
-for changing parameter settings.
+On EDB Postgres Extended Server and EDB Postgres Advanced Server, BDR will
+automatically hold back the freezing of rows while a node is down to handle
+this situation gracefully without the need for changing parameter settings.
 
 On other variants of Postgres, users may need to manage this situation with
 some care:

diff --git a/product_docs/docs/bdr/4.0/crdt.mdx b/product_docs/docs/bdr/4.0/crdt.mdx
@@ -163,10 +163,6 @@ new data types. CRDT types are handled transparently - both `ANALYZE` and
 the optimizer work, so estimation and query planning works fine, without
 having to do anything else.
 
-!!! Note
-    This feature is currently only available on EDB Postgres Extended and
-    EDB Postgres Advanced.
-
 ## State-based and operation-based CRDTs
 
 Following the notation from [1], we do implement both operation-based

diff --git a/product_docs/docs/bdr/4.0/credits.mdx b/product_docs/docs/bdr/4.0/credits.mdx
diff --git a/product_docs/docs/bdr/4.0/ddl.mdx b/product_docs/docs/bdr/4.0/ddl.mdx
@@ -639,7 +639,6 @@ DML lock:
 -   `ALTER TABLE ... ALTER COLUMN ... SET DEFAULT expression`
 -   `ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT`
 -   `ALTER TABLE ... ALTER COLUMN ... TYPE` if it does not require rewrite
-    (currently only available on EDB Postgres Extended and EDB Postgres Advanced)
 -   `ALTER TABLE ... ALTER COLUMN ... SET STATISTICS`
 -   `ALTER TABLE ... VALIDATE CONSTRAINT`
 -   `ALTER TABLE ... ATTACH PARTITION`
@@ -811,10 +810,6 @@ could lead to table rewrites lasting long durations.
 Also note that the above implicit castable ALTER activity cannot be
 performed in transaction blocks.
 
-!!! Note
-    This currently only works on EDB Postgres Extended and EDB Postgres
-    Advanced.
-
 ### ALTER TYPE
 
 Users should note that `ALTER TYPE` is replicated but a Global DML lock is *not*
@@ -846,16 +841,8 @@ allowed on a BDR node.
 
 ### CREATE TABLE AS and SELECT INTO 
 
-`CREATE TABLE AS` and `SELECT INTO` are only allowed on EDB Postgres Extended
-and EDB Postgres Advanced and only if any sub-commands are also allowed.
-
-You can instead achieve the same effect using, in case the
-`CREATE TABLE AS` is not supported on your variant of Postgres:
-
-```
-CREATE TABLE mytable;
-INSERT INTO mytable SELECT ... ;
-```
+`CREATE TABLE AS` and `SELECT INTO` are only allowed if all sub-commands are
+also allowed.
 
 ### EXPLAIN
 
@@ -972,8 +959,8 @@ locking.
 
 #### Adding a CONSTRAINT
 
-Starting BDR 3.7.4, a CHECK and FOREIGN KEY constraint can be added
-without requiring a DML lock. This requires a 2-step process.
+CHECK and FOREIGN KEY constraint can be added without requiring a DML lock.
+This requires a 2-step process.
 
 -   `ALTER TABLE ... ADD CONSTRAINT ... NOT VALID`
 -   `ALTER TABLE ... VALIDATE CONSTRAINT`
@@ -994,10 +981,6 @@ Note that the new facility requires the cluster to run with Raft protocol
 version 24 and beyond. If the Raft protocol is not yet upgraded, the old
 mechanism will be used, resulting in a DML lock request.
 
-!!! Note
-    This currently only works on EDB Postgres Extended and EDB Postgres
-    Advanced.
-
 #### Adding a Column
 
 To add a column with a volatile default, run these commands in

diff --git a/product_docs/docs/bdr/4.0/feature-matrix.mdx b/product_docs/docs/bdr/4.0/feature-matrix.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Appendix B: Feature Compatibility'
+title: 'Appendix A: Feature Compatibility'
 originalFilePath: feature-matrix.md
 
 ---
@@ -11,14 +11,15 @@ PostgreSQL, EDB Postgres Extended and EDB Postgres Advanced variants of Postgres
 The following table lists features of BDR and whether they are supported by
 given variant of Postgres and optionally from which version.
 
-| Feature                                | PostgreSQL | EDB Postgres Extended | EDB Postgres Advanced |
-| -------------------------------------- | ---------- | --------------------- | --------------------- |
-| Commit At Most Once (CAMO)             | N          | Y                     | 14+                   |
-| Eager Replication                      | N          | Y                     | 14+                   |
-| Decoding Worker                        | N          | 13+                   | 14+                   |
-| Assesment Tooling                      | N          | Y                     | 14+                   |
-| Lag Tracker                            | N          | Y                     | 14+                   |
-| Timestamp Snapshots                    | N          | Y                     | 14+                   |
-| Transaction Streaming                  | 14+        | 13+                   | 14+                   |
-| Missing Partition Conflict             | N          | Y                     | 14+                   |
-| No UPDATE Trigger on tables with TOAST | N          | Y                     | 14+                   |
+| Feature                                         | PostgreSQL | EDB Postgres Extended | EDB Postgres Advanced |
+| ----------------------------------------------- | ---------- | --------------------- | --------------------- |
+| Commit At Most Once (CAMO)                      | N          | Y                     | 14+                   |
+| Eager Replication                               | N          | Y                     | 14+                   |
+| Decoding Worker                                 | N          | 13+                   | 14+                   |
+| Assesment Tooling                               | N          | Y                     | 14+                   |
+| Lag Tracker                                     | N          | Y                     | 14+                   |
+| Timestamp Snapshots                             | N          | Y                     | 14+                   |
+| Transaction Streaming                           | 14+        | 13+                   | 14+                   |
+| Missing Partition Conflict                      | N          | Y                     | 14+                   |
+| No need for UPDATE Trigger on tables with TOAST | N          | Y                     | 14+                   |
+| Automatically hold back FREEZE                  | N          | Y                     | 14+                   |