Merge pull request #2676 from EnterpriseDB/release/2022-05-17

Release: 2022-05-17

product_docs/docs/bdr/4/index.mdx

@@ -26,7 +26,6 @@ navigation:
   - twophase
   - catalogs
   - functions
-  - feature-matrix
   - known-issues
 title: BDR (Bi-Directional Replication)
 directoryDefaults:
@@ -52,16 +51,8 @@ Detailed overview about how BDR works is described in the
 
 BDR is compatible with PostgresSQL, EDB Postgres Extended and EDB Postgres
 Advanced flavors of PostgresSQL database servers and can be deployed as a
-standard PG extension. Full compatibility matrix is as follows.
-
-| BDR Version | PostgreSQL | EDB Postgres Extended | EDB Postgres Advanced |
-| ----------- | ---------- | --------------------- | --------------------- |
-| 4.0.2       | 14.2       | 14.2                  | 14.2                  |
-| 4.0.2       | 13.6       | 13.6r1.1.8            | 13.6                  |
-| 4.0.2       | 12.10      | 12.10r1.1.10          | 12.10                 |
-| 3.7.15      | 13.6       | 13.6r1.1.8            | 13.6                  |
-| 3.7.15      | 12.10      | 12.10r1.1.10          | 12.10                 |
-| 3.7.15      | 11.15      | 11.15r2.1.10          | 11.15                 |
+standard PG extension. See [Comptibility Matrix](pgd/latest/compatibility_matrix/)
+for details of supported version combinations.
 
 It is important to note that some key BDR features depend on certain core
 capabilities being available within the targeted PostgresSQL database server.
@@ -71,7 +62,7 @@ example, if having the BDR feature "Commit At Most Once (CAMO)" is mission
 critical to a BDR customer’s use case, they should not adopt the community
 PostgreSQL flavor for it does not have the core capability required to handle
 CAMO. The full feature matrix compatibility can be found in
-[Feature Compatibility](feature-matrix) appendix.
+[Choosing a Postgres distribution](/pgd/latest/choosing_server/).
 
 BDR offers close to native PostgreSQL compatibility. However, some access
 patterns don't necessarily work as well in multi-node setup as they do on

product_docs/docs/bdr/4/known-issues.mdx

@@ -1,5 +1,5 @@
 ---
-title: 'Appendix B: Known Issues'
+title: 'Appendix A: Known Issues'
 
 
 ---

product_docs/docs/bdr/4/release_notes/bdr4_rel_notes.mdx

@@ -10,8 +10,8 @@ versions are 3.7 and 3.6.
 | ---- | -------- | ----------- |
 | Feature | Compatibility | BDR on EDB Postgres Advanced 14 now supports following features which were previously only available on EDB Postgres Extended: <br />-   Commit At Most Once - a consistency feature helping an application to commit each transaction only once, even in the presence of node failures <br />-   Eager Replication - synchronizes between the nodes of the cluster before committing a transaction to provide conflict free replication<br />-   Decoding Worker - separation of decoding into separate worker from wal senders allowing for better scalability with many nodes<br />-   Estimates for Replication Catch-up times<br />-   Timestamp-based Snapshots - providing consistent reads across multiple nodes for retrieving data as they appeared or will appear at a given time<br />-   Automated dynamic configuration of row freezing to improve consistency of UPDATE/DELETE conflicts resolution in certain corner cases<br />-   Assesment checks<br />-   Support for handling missing partitions as conflicts rather than errors<br />-   Advanced DDL Handling for NOT VALID constraints and ALTER TABLE
 | Feature | Compatibility | BDR on community version of PostgreSQL 12-14 now supports following features which were previously only available on EDB Postgres Advanced or EDB Postgres Extended:<br />-   Conflict-free Replicated Data Types - additional data types which provide mathematically proven consistency in asynchronous multi-master update scenarios<br />-   Column Level Conflict Resolution - ability to use per column last-update wins resolution so that UPDATEs on different fields can be "merged" without losing either of them<br />-   Transform Triggers - triggers that are executed on the incoming stream of data providing ability to modify it or to do advanced programmatic filtering<br />-   Conflict triggers - triggers which are called when conflict is detected, providing a way to use custom conflict resolution techniques<br />-   CREATE TABLE AS replication<br />-   Parallel Apply - allow multiple writers to apply the incoming changes
-| Feature | Performance | Support streaming of large transactions. <p> This allows BDR to stream a large transaction (greater than `logical_decoding_work_mem` in size) either to a file on the downstream or to a writer process. This ensures that the transaction is decoded even before it's committed, thus improving parallelism. Further, the transaction can even be applied concurrently if streamed straight to a writer. This improves parallelism even more. </p><p> When large transactions are streamed to files, they are decoded and the decoded changes are sent to the downstream even before they are committed. The changes are written to a set of files and applied when the transaction finally commits. If the transaction aborts, the changes are discarded, thus wasting resources on both upstream and downstream. </p><p> Sub-transactions are also handled automatically. </p><p> This feature is available on PostgreSQL 14, EDB Postgres Extended 13+ and EDB Postgres Advanced 14, see [Feature Compatibility](feature-matrix) appendix for more details on which features can be used on which versions of Postgres.</p>
-| Feature | Compatibility | The differences that existed in earlier versions of BDR between standard and enterprise edition have been removed. With BDR 4.0 there is one extension for each supported Postgres distribution and version, i.e., PostgreSQL v12-14, EDB Postgres Extended v12-14, and EDB Postgres Advanced 12-14. <p> Not all features are available on all versions of PostgreSQL, the available features are reported via feature flags using either `bdr_config` command line utility or `bdr.bdr_features()` database function. See [Feature Compatibility](feature-matrix) appendix for more details.</p>
+| Feature | Performance | Support streaming of large transactions. <p> This allows BDR to stream a large transaction (greater than `logical_decoding_work_mem` in size) either to a file on the downstream or to a writer process. This ensures that the transaction is decoded even before it's committed, thus improving parallelism. Further, the transaction can even be applied concurrently if streamed straight to a writer. This improves parallelism even more. </p><p> When large transactions are streamed to files, they are decoded and the decoded changes are sent to the downstream even before they are committed. The changes are written to a set of files and applied when the transaction finally commits. If the transaction aborts, the changes are discarded, thus wasting resources on both upstream and downstream. </p><p> Sub-transactions are also handled automatically. </p><p> This feature is available on PostgreSQL 14, EDB Postgres Extended 13+ and EDB Postgres Advanced 14, see [Choosing a Postgres distribution](/pgd/latest/choosing_server/) appendix for more details on which features can be used on which versions of Postgres.</p>
+| Feature | Compatibility | The differences that existed in earlier versions of BDR between standard and enterprise edition have been removed. With BDR 4.0 there is one extension for each supported Postgres distribution and version, i.e., PostgreSQL v12-14, EDB Postgres Extended v12-14, and EDB Postgres Advanced 12-14. <p> Not all features are available on all versions of PostgreSQL, the available features are reported via feature flags using either `bdr_config` command line utility or `bdr.bdr_features()` database function. See [Choosing a Postgres distribution](/pgd/latest/choosing_server/) for more details.</p>
 | Feature | User Experience | There is no pglogical 4.0 extension that corresponds to the BDR 4.0 extension. BDR no longer has a requirement for pglogical. <p> This means also that only BDR extension and schema exist and any configuration parameters were renamed from `pglogical.` to `bdr.`.</p>
 | Feature | Initial experience | Some configuration options have change defaults for better post-install experience:<br />-   Parallel apply is now enabled by default (with 2 writers). Allows for better performance, especially with streaming enabled.<br />-   `COPY` and `CREATE INDEX CONCURRENTLY` are now streamed directly to writer in parallel (on Postgres versions where streaming is supported) to all available nodes by default, eliminating or at least reducing replication lag spikes after these operations.<br />-   The timeout for global locks have been increased to 10 minutes<br />-   The `bdr.min_worker_backoff_delay` now defaults to 1s so that subscriptions retry connection only once per second on error
 | Feature | Reliability and operability | Greatly reduced the chance of false positives in conflict detection during node join for table that use origin based conflict detection

product_docs/docs/harp/2/01_release_notes/harp2.1.0_rel_notes.mdx

@@ -7,7 +7,6 @@ as fixes for issues identified in previous versions.
 
 | Type | Description |
 | ---- |------------ |
-| Feature | Support for selecting a leader per location rather than relying on DCS like etcd to have separate setup in different locations. <p>This still requires a majority of nodes to survive loss of a location, so an odd number of both locations and database nodes is recommended.</p> |
 | Feature | The BDR DCS now uses a push notification from the consensus rather than through polling nodes. <p>This change reduces the time for new leader selection and the load that HARP does on the BDR DCS since it doesn't need to poll in short intervals anymore.</p> |
 | Feature | TPA now restarts each HARP Proxy one by one and wait until they come back to reduce any downtime incurred by the application during software upgrades. |
 | Feature | The support for embedding PGBouncer directly into HARP Proxy is now deprecated and will be removed in the next major release of HARP. <p>It's now possible to configure TPA to put PGBouncer on the same node as HARP Proxy and point to that HARP Proxy. </p> |

product_docs/docs/odbc_connector/13/01_odbc_rel_notes/02_odbc_13.2.0.01_rel_notes.mdx

@@ -0,0 +1,10 @@
+---
+title: "Version 13.02.0000.01"
+---
+
+EDB ODBC Connector 13.02.0000.01 includes the following enhancement:
+
+| Type           | Description                                              |
+| -------------- | -------------------------------------------------------- | 
+| Upstream merge | Merged with the upstream community driver version 13.02.0000. See the community [Release notes](https://odbc.postgresql.org/docs/release.html) for details. |
+| Bug fix        | MS SQL linked server repetition of databases [Support ticket #1044249]. |

product_docs/docs/odbc_connector/13/01_odbc_rel_notes/index.mdx

@@ -8,6 +8,7 @@ Release notes describe what's new in a release. When a minor or patch release in
 
 | Version                                   | Release date | 
 | ----------------------------------------- | ------------ | 
-| [13.01.0000.02](01_odbc_13.1.0.02_rel_notes) | 2021 Dec 12  |
-| [13.01.0000.01](03_odbc_13.1.0.01_rel_notes) | 2021 Sep 14  |
+| [13.02.0000.01](02_odbc_13.2.0.01_rel_notes) | 2022 May 17 |
+| [13.01.0000.02](03_odbc_13.1.0.02_rel_notes) | 2021 Dec 12  |
+| [13.01.0000.01](04_odbc_13.1.0.01_rel_notes) | 2021 Sep 14  |
 | [13.00.0000.01](05_odbc_13.0.0.01_rel_notes) | 2020 Nov 19  |

product_docs/docs/odbc_connector/13/05_edb-odbc_connection_properties.mdx

@@ -118,6 +118,7 @@ Select **Page 2** (in the upper-left corner of the Advanced Options dialog box)
 -   Select **Read Only** to prevent the driver from executing the following commands: `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `ALTER`, `DROP`, `GRANT`, `REVOKE` or `LOCK`. Invoking the **Read Only** option also prevents any calls that use ODBC’s procedure call escape syntax (`call=procedure-name?`). By default, this option is off.
 -   Select **Show System Tables** to include system tables in the result set of the `SQLTables()` function. If the option is enabled, the driver includes any table whose name starts with `pg\_` or any of the prefixes listed in the **SysTablePrefixes** field of Page 1 of the Advanced Options dialog box. By default, this option is off.
 -   Select **Show sys/dbo Tables [Access]** to access objects in the `sys` schema and `dbo` schema through the ODBC data source. By default, this option is on.
+-   Select **Show sys/SQL Tables** to enable accessing database tables in a linked server with MS SQL.
 -   Select **Cumulative Row Count for Insert** to cause a single, cumulative row count to be returned for the entire array of parameter settings for an `INSERT` statement when a call to the `SQLRowCount()` method is performed. If this option is cleared, then an individual row count is available for each parameter setting in the array and thus a call to `SQLRowCount()` returns the count for the last inserted row.
 -   Select **LF<->CR/LF** conversion to instruct the driver to convert line-feed characters to carriage-return/line-feed pairs when fetching character values from the server and convert them back to line-feed characters when sending character values to the server. By default, this option is on.
 -   Select **Updatable Cursors** to specify for the driver to permit positioned `UPDATE` and `DELETE` operations with the `SQLSetPos()` or `SQLBulkOperations()` functions. By default, this option is on.

product_docs/docs/pgd/4/architectures/gold.mdx

@@ -3,7 +3,6 @@ title: "AlwaysOn Gold (two active locations - cloud regions or on prem data cent
 navTitle: "Gold"
 ---
 
-The AlwaysOn Gold architecture is ideal for production environments where customers are ......
 
 This architecture favors local resiliency/redundancy first and remote locations only when and an entire location is offline or fails.