Merge pull request #5084 from EnterpriseDB/release/2023-12-12

Release/2023-12-12

advocacy_docs/supported-open-source/postgresql/overview.mdx

@@ -11,7 +11,7 @@ EDB's PostgreSQL installers and installation packages simplify the process of in
 - The Stack Builder package manager for Windows and MacOS. Use this utility to download and install drivers, tools, and applications to complement your PostgreSQL installation.
 
 To obtain PostgreSQL installers and installation packages:
-- EDB provides installers and installation packages for most common computing platforms. [EDB installation documention](installing) describes how to obtain installers and installation packages from an EDB repo.
+- EDB provides installers and installation packages for most common computing platforms. [EDB installation documentation](installing) describes how to obtain installers and installation packages from an EDB repo.
 - The PostgreSQL community provides installers and installation packages for most computing platforms. For more information, see the [PostgreSQL downloads page](https://www.postgresql.org/download/).
 
 EDB also makes PostgreSQL Early Experience distributions available. For details, see [PostgreSQL Early Experience](https://www.enterprisedb.com/postgresql-early-experience).

advocacy_docs/supported-open-source/postgresql/uninstalling.mdx

@@ -19,9 +19,9 @@ The PostgreSQL installer creates an uninstaller in the PostgreSQL installation d
 
 ## Uninstalling PostgreSQL on Windows
 
-1.  On the Windows Control Panel, open the Uninstall or change a program dialog box. 
+1.  On the Windows Control Panel, open the Uninstall or Change a Program dialog box. 
 
-  ![The Uninstall or change a program dialog box](/installing/images/change_program.png)
+  ![The Uninstall or Change a Program dialog box](/installing/images/change_program.png)
 
 1. Right-click **PostgreSQL**, and select **Uninstall/Change** from the context menu.
 
@@ -31,11 +31,11 @@ The PostgreSQL installer creates an uninstaller in the PostgreSQL installation d
 
     - To remove the entire application, select **Entire application** and select **Next**.
     - To remove individual components, select **Individual components** and select **Next**. Then, from the list, select the components to uninstall, and select **Next**.
-
-  ![Select the components to uninstall](/installing/images/select_the_components_to_uninstall.png)
+    
+    ![Select the components to uninstall](/installing/images/select_the_components_to_uninstall.png)
 
   A progress bar keeps you informed as PostgreSQL is removed.
-
+  
   ![Uninstalling PostgreSQL](/installing/images/uninstalling_postgreSQL.png)
 
 1.  When the uninstaller completes, select **OK**.
@@ -53,10 +53,10 @@ These instructions apply if you used EDB's interactive Mac installer to install
 To uninstall PostgreSQL on a Mac system:
 
 !!! Note Data is not deleted
-This uninstaller will remove the application but, to avoid data loss, will
-leave in place the Postgres data directory and the postgres user that was
-created to manage the installation. The uninstaller will popup a message
-confirming what it has not been removed at the end of its run.
+This uninstaller removes the application but, to avoid data loss,
+leaves in place the Postgres data directory and the postgres user that was
+created to manage the installation. At the end of its run, the uninstaller 
+displays a message confirming that it didn't remove the data directory or user.
 !!!
 
 1.  Invoke the uninstaller:
@@ -70,20 +70,19 @@ confirming what it has not been removed at the end of its run.
 1.  You're prompted for a password. If your user has admin rights on macOS, enter your password. Otherwise, enter the user name and password of a user with admin rights. 
 
   The uninstaller opens and asks if you want to uninstall the entire application or individual components. 
-
+  
   ![Remove the entire application or components](/installing/images/remove_the_entire_application_or_components.png)
 
 1.  Respond to the installer:
 
     -  To remove the entire application, select **Entire application**, and select **Next**.
     -  To remove individual components, select **Individual components**. Select the components to uninstall, and select **Next** to start uninstalling components.
-
+    
   ![Selecting the components to uninstall](/installing/images/selecting_the_components_to_uninstall.png)
 
   Progress bars appear as each component is removed. 
 
 1.  When the uninstaller completes, select **OK**.
 
-![The Uninstallation is completed](/installing/images/mac_uninstallation_completed.png)
-
+  ![The Uninstallation is completed](/installing/images/mac_uninstallation_completed.png)
 

package.json

@@ -111,7 +111,7 @@
   },
   "lint-staged": {
     "*.js": "prettier --write"
-  },  
+  },
   "repository": {
     "type": "git",
     "url": "https://github.com/EnterpriseDB/docs"

product_docs/docs/efm/4/04_configuring_efm/04_extending_efm_permissions.mdx

@@ -21,7 +21,7 @@ The `efm_db_functions` or `efm_root_functions` scripts perform management functi
 
 The `sudoers` file contains entries that allow the user efm to control the Failover Manager service for clusters owned by postgres or enterprisedb. You can modify a copy of the `sudoers` file to grant permission to efm to manage Postgres clusters owned by other users.
 
-The `efm-42` file is located in `/etc/sudoers.d` and contains the following entries:
+The `efm-48` file is located in `/etc/sudoers.d` and contains the following entries:
 
 ```text
 # Copyright EnterpriseDB Corporation, 2014-2021. All Rights Reserved.
@@ -53,7 +53,7 @@ efm    ALL=(ALL)           NOPASSWD:   /usr/edb/efm-4.8/bin/efm_pgpool_functions
 Defaults:efm !requiretty
 ```
 
-If you're using Failover Manager to monitor clusters that are owned by users other than postgres or enterprisedb, make a copy of the `efm-42` file and modify the content to allow the user to access the `efm_functions` script to manage their clusters.
+If you're using Failover Manager to monitor clusters that are owned by users other than postgres or enterprisedb, make a copy of the `efm-48` file. Then modify the content to allow the user to access the `efm_functions` script to manage their clusters.
 
 If an agent can't start because of permission problems, make sure the default `/etc/sudoers` file contains the following line at the end of the file:
 

product_docs/docs/pgd/4/upgrades/upgrade_paths.mdx

@@ -7,6 +7,19 @@ title: Supported BDR upgrade paths
 Beginning with version 4, EDB Postgres Distributed adopted [semantic versioning](https://semver.org/). All changes within the same major version are backward compatible, lowering the risk when upgrading and allowing you to choose any later minor or patch release as the upgrade target. You can upgrade from any version 4.x release to a later 4.x release.
 
 
+Due to interdependencies between EDB Postgres Distributed and EDB Postgres Advanced Server or EDB Postgres Extended, there are occasions when it is important to always upgrade both components at once. More detailed compatibility information can be found below.
+
+ PGD version     | EPAS version            | PGE version 
+-----------------|-------------------------|------------------
+Up to 4.3.0      | Up to 14.7 / 15.2       | Up to 14.9 / 15.4
+4.3.1, 4.3.2     | 14.8, 14.9 / 15.3, 15.4 | Up to 14.9/ 15.4
+4.3.3 and higher | 14.10 / 15.5 and higher | 14.10 / 15.5 and higher
+
+This dependency is bidirectional dependency. 
+
+* Upgrading your Postgres servers will require you to upgrade your PGD installation to the relevant version.
+* Upgrading your PGD installation will require you to upgrade your Postgres servers to the relevant version.
+
 ## Upgrading from version 3.7 to version 4
 
 Generally, we recommend that you upgrade to the latest version 3.7 release before

product_docs/docs/pgd/5/choosing_server.mdx

@@ -23,7 +23,7 @@ The following table lists features of EDB Postgres Distributed that are dependen
 | [Transform triggers](striggers/#transform-triggers)                              | Y          | Y                     | Y                     |
 | [Conflict triggers](striggers/#conflict-triggers)                               | Y          | Y                     | Y                     |
 | [Asynchronous replication](durability/)                        | Y          | Y                     | Y                     |
-| [Legacy synchronous replication](durability/#legacy-synchronous-replication-using-pgd)                  | Y          | Y                     | Y                     |
+| [Legacy synchronous replication](durability/legacy-sync)                  | Y          | Y                     | Y                     |
 | [Group Commit](durability/group-commit/)                                    | N          | Y                     | 14+                   |
 | [Commit At Most Once (CAMO)](durability/camo/)                      | N          | Y                     | 14+                   |
 | [Eager Conflict Resolution](consistency/eager/)                       | N          | Y                     | 14+                   |

product_docs/docs/pgd/5/durability/administering.mdx

@@ -0,0 +1,22 @@
+---
+title: Administering
+navTitle: Administering
+---
+
+When running a PGD cluster with Group Commit, there are some things you need to
+be aware of when administering the system, such as how to safely shut down and 
+restart nodes.
+
+## Planned shutdown and restarts
+
+When using Group Commit with receive confirmations, take care
+with planned shutdown or restart. By default, the apply queue is processed
+prior to shutting down. However, in the `immediate` shutdown mode, the queue
+is discarded at shutdown, leading to the stopped node "forgetting"
+transactions in the queue. A concurrent failure of the origin node can
+lead to loss of data, as if both nodes failed.
+
+To ensure the apply queue gets flushed to disk, use either
+[`smart` or `fast` shutdown](https://www.postgresql.org/docs/current/server-shutdown.html) for maintenance tasks. This approach maintains the
+required synchronization level and prevents loss of data.
+