From d02e16554082ae861e6617419693b0211b797ca8 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Tue, 13 Aug 2024 12:22:27 +0200 Subject: [PATCH 01/17] Intro to EPRS LOB batch mode --- .../02_optimize_sync_replication/using_bacth_lob | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob new file mode 100644 index 00000000000..be932da0991 --- /dev/null +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob @@ -0,0 +1,13 @@ +--- +title: "Using batch synchronization for LOB objects" +--- + +When synchronizing Large Objects or LOBs, by default the Replication Server copies them row by row. This can make the synchronization process slow. + +To improve the performance of synchronization procedures, EDB supports configuring the batch mode on LOBs. Configuring batch synchronization of LOBs allows the Replication Server to copy several LOBs at the same time, making the synchronization of shadow tables faster. + +When enabling this option, the default number of parallel LOB copies is 100. You can configure that number according to your replication needs and resource availability, since this will increase memory consumption. + +## Enabling batch operations on Large Objects + +## Configuring the number of parallel operations \ No newline at end of file From d90e34b481f8d44a90ba3a19b170d4b05d0ca4cb Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Tue, 13 Aug 2024 14:26:19 +0200 Subject: [PATCH 02/17] edits --- .../02_optimize_sync_replication/using_bacth_lob | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob index be932da0991..a8c0477109d 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob @@ -2,11 +2,11 @@ title: "Using batch synchronization for LOB objects" --- -When synchronizing Large Objects or LOBs, by default the Replication Server copies them row by row. This can make the synchronization process slow. +When synchronizing Large Objects or LOBs, by default, the Replication Server copies them row by row. This can make the synchronization process slow. -To improve the performance of synchronization procedures, EDB supports configuring the batch mode on LOBs. Configuring batch synchronization of LOBs allows the Replication Server to copy several LOBs at the same time, making the synchronization of shadow tables faster. +To improve the performance of synchronization procedures, EDB supports copying LOBs in batches. This way, the Replication Server can copy several LOBs at the same time, making the synchronization of shadow tables faster. -When enabling this option, the default number of parallel LOB copies is 100. You can configure that number according to your replication needs and resource availability, since this will increase memory consumption. +When enabling this option, the default number of parallel LOB copies is 100. Before enabling the batch mode, or increasing the number of simultaneous synchronization procedures for LOB objects, consider your resource availability, as batch procedures will increase memory consumption. ## Enabling batch operations on Large Objects From f90e051daa5477286df57bbc958d020124190433 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 14 Aug 2024 13:00:37 +0200 Subject: [PATCH 03/17] Added steps and reworded the intro --- .../using_bacth_lob | 13 ------- .../using_bacth_lob.mdx | 37 +++++++++++++++++++ 2 files changed, 37 insertions(+), 13 deletions(-) delete mode 100644 product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob create mode 100644 product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob deleted file mode 100644 index a8c0477109d..00000000000 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "Using batch synchronization for LOB objects" ---- - -When synchronizing Large Objects or LOBs, by default, the Replication Server copies them row by row. This can make the synchronization process slow. - -To improve the performance of synchronization procedures, EDB supports copying LOBs in batches. This way, the Replication Server can copy several LOBs at the same time, making the synchronization of shadow tables faster. - -When enabling this option, the default number of parallel LOB copies is 100. Before enabling the batch mode, or increasing the number of simultaneous synchronization procedures for LOB objects, consider your resource availability, as batch procedures will increase memory consumption. - -## Enabling batch operations on Large Objects - -## Configuring the number of parallel operations \ No newline at end of file diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx new file mode 100644 index 00000000000..b1cfd115909 --- /dev/null +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -0,0 +1,37 @@ +--- +title: "Using batch synchronization for LOB objects" +--- + +When synchronizing tables with LOB type columns (BLOB, CLOB, BYTEA etc.), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when a LOB column has more than 100 MB of data. However, replicating data in 5-row batches can make the synchronization process slow. + +To improve the performance of synchronization procedure, reduce network roundtrips and speed up data replication, EDB supports copying row with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of shadow tables faster. EDB recommends configuring larger batches only if the average data size per column is smaller than 100 MB. + +You can configure the replication of up to 1000 rows per batch. + +!!!note + Before increasing the number of rows to synchronize per batch, consider resource availability. Batch procedures increase memory consumption during replication processes. +!!! + +## Enabling batch operations on LOBs + +### Prerequisites + +You have upgraded your instance to a Replication Server version that includes this feature. + +See [Release Notes](../../../eprs_rel_notes) for an overview of the available release versions. + +### Altering the number of rows per batch + +1. Open the `xdb_pubserver.conf` file. + +1. Look for the `syncLOBBatchSize` value. If not uncommented already, uncomment the line to enable batch processes. + +1. Adapt the `syncLOBBatchSize` value according to your needs. In this example, the Replication Server will synchronize 150 rows with LOB data per batch: + + ``` + syncLOBBatchSize=150 + ``` + +1. Reload the configuration file as specified in [Reloading the configuration file](../../../08_xdb_cli/03_xdb_cli_commands/52_reload_conf_file). + +Now, each time you take a snapshot and start a replication process, Replication Server will copy 150 rows with LOB objects per batch. This applies to both manual and scheduled synchronization procedures. \ No newline at end of file From ca3c4b9beac327f0624bec8e3efa3175b1da9bd2 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 14 Aug 2024 15:07:33 +0200 Subject: [PATCH 04/17] Added further clarification and link references --- .../using_bacth_lob.mdx | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index b1cfd115909..bb8a15360b1 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -2,9 +2,9 @@ title: "Using batch synchronization for LOB objects" --- -When synchronizing tables with LOB type columns (BLOB, CLOB, BYTEA etc.), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when a LOB column has more than 100 MB of data. However, replicating data in 5-row batches can make the synchronization process slow. +When synchronizing tables with LOB type columns (BLOB, CLOB, BYTEA etc.), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has more than 100 MB of data. However, replicating data in 5-row batches can make the synchronization process slow. -To improve the performance of synchronization procedure, reduce network roundtrips and speed up data replication, EDB supports copying row with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of shadow tables faster. EDB recommends configuring larger batches only if the average data size per column is smaller than 100 MB. +To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, EDB supports copying rows with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of shadow tables faster. EDB recommends configuring larger batches only if the average data size per LOB column is smaller than 100 MB. You can configure the replication of up to 1000 rows per batch. @@ -16,17 +16,17 @@ You can configure the replication of up to 1000 rows per batch. ### Prerequisites -You have upgraded your instance to a Replication Server version that includes this feature. - -See [Release Notes](../../../eprs_rel_notes) for an overview of the available release versions. +You have upgraded your instances to a Replication Server version that includes this feature. See [Release Notes](../../../eprs_rel_notes) for an overview of the available release versions and the included enhancements. ### Altering the number of rows per batch -1. Open the `xdb_pubserver.conf` file. +1. In the publication or primary server, open the `xdb_pubserver.conf` file. + + See [Installation details](../../../installing/installation_details/#additional-details) to find out where this file is stored according to your operating system. -1. Look for the `syncLOBBatchSize` value. If not uncommented already, uncomment the line to enable batch processes. +1. In the `xdb_pubserver.conf` file, look for the `syncLOBBatchSize` value. -1. Adapt the `syncLOBBatchSize` value according to your needs. In this example, the Replication Server will synchronize 150 rows with LOB data per batch: +1. Adapt the `syncLOBBatchSize` value according to your needs. If not uncommented already, uncomment the line to override the default. In this example, the Replication Server will synchronize 150 rows with LOB data per batch: ``` syncLOBBatchSize=150 @@ -34,4 +34,4 @@ See [Release Notes](../../../eprs_rel_notes) for an overview of the available re 1. Reload the configuration file as specified in [Reloading the configuration file](../../../08_xdb_cli/03_xdb_cli_commands/52_reload_conf_file). -Now, each time you take a snapshot and start a replication process, Replication Server will copy 150 rows with LOB objects per batch. This applies to both manual and scheduled synchronization procedures. \ No newline at end of file +Now, each time you take a snapshot and start a replication process, Replication Server will copy 150 rows with LOB objects per network roundtrip. This applies to both manual and scheduled synchronization procedures. \ No newline at end of file From 95563821248e1826392bc6fcd7f5404c8d43e63c Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Thu, 15 Aug 2024 11:25:56 +0200 Subject: [PATCH 05/17] Implemented feedback from Abbas --- .../02_optimize_sync_replication/using_bacth_lob.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index bb8a15360b1..cca233363f7 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -2,9 +2,9 @@ title: "Using batch synchronization for LOB objects" --- -When synchronizing tables with LOB type columns (BLOB, CLOB, BYTEA etc.), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has more than 100 MB of data. However, replicating data in 5-row batches can make the synchronization process slow. +When synchronizing tables with LOB-type columns (with BLOB, CLOB, BYTEA etc. objects), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has a large amount of data. You can customize the batch size to increase or decrease the number of rows copied in a batch. -To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, EDB supports copying rows with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of shadow tables faster. EDB recommends configuring larger batches only if the average data size per LOB column is smaller than 100 MB. +To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, EDB supports copying rows with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of tables faster. EDB recommends configuring larger batches only if the instance hosting the replication server has enough memory. You can configure the replication of up to 1000 rows per batch. @@ -34,4 +34,4 @@ You have upgraded your instances to a Replication Server version that includes t 1. Reload the configuration file as specified in [Reloading the configuration file](../../../08_xdb_cli/03_xdb_cli_commands/52_reload_conf_file). -Now, each time you take a snapshot and start a replication process, Replication Server will copy 150 rows with LOB objects per network roundtrip. This applies to both manual and scheduled synchronization procedures. \ No newline at end of file +Now, each time you perform a synchronization, the Replication Server will copy 150 rows with LOB objects per network roundtrip. This applies to both manual and scheduled replication procedures. \ No newline at end of file From cea756c902d38d6ab884cdf03a43c3a4793338d0 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Fri, 16 Aug 2024 08:44:58 +0200 Subject: [PATCH 06/17] Removing redundant information. --- .../02_optimize_sync_replication/using_bacth_lob.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index cca233363f7..10664fbfa3b 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -34,4 +34,4 @@ You have upgraded your instances to a Replication Server version that includes t 1. Reload the configuration file as specified in [Reloading the configuration file](../../../08_xdb_cli/03_xdb_cli_commands/52_reload_conf_file). -Now, each time you perform a synchronization, the Replication Server will copy 150 rows with LOB objects per network roundtrip. This applies to both manual and scheduled replication procedures. \ No newline at end of file +Now, each time you perform a synchronization, the Replication Server will copy 150 rows with LOB objects per network roundtrip. From 7d9a1a3d642850acb788877fbcbbffa611b41ba8 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Mon, 19 Aug 2024 15:10:52 +0200 Subject: [PATCH 07/17] Implemented feedback from Josh E. --- .../02_optimize_sync_replication/using_bacth_lob.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index 10664fbfa3b..80e5c13b6db 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -4,7 +4,7 @@ title: "Using batch synchronization for LOB objects" When synchronizing tables with LOB-type columns (with BLOB, CLOB, BYTEA etc. objects), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has a large amount of data. You can customize the batch size to increase or decrease the number of rows copied in a batch. -To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, EDB supports copying rows with LOBs in larger batches. This way, the Replication Server can copy several rows at the same time, making the synchronization of tables faster. EDB recommends configuring larger batches only if the instance hosting the replication server has enough memory. +To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, you can copy rows with LOBs in larger batches. Configure larger batches only if the instance hosting the replication server has enough memory. You can configure the replication of up to 1000 rows per batch. From 6cd234bb4d231e1eb2f951f3f93acb44b8782270 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 21 Aug 2024 09:31:46 +0200 Subject: [PATCH 08/17] Removing definite article from product name --- .../02_optimize_sync_replication/using_bacth_lob.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index 80e5c13b6db..e6ae9713b4f 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -2,7 +2,7 @@ title: "Using batch synchronization for LOB objects" --- -When synchronizing tables with LOB-type columns (with BLOB, CLOB, BYTEA etc. objects), the Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has a large amount of data. You can customize the batch size to increase or decrease the number of rows copied in a batch. +When synchronizing tables with LOB-type columns (with BLOB, CLOB, BYTEA etc. objects), Replication Server copies the rows by grouping 5 rows in a batch by default. This is to avoid causing out-of-memory errors when an LOB column has a large amount of data. You can customize the batch size to increase or decrease the number of rows copied in a batch. To improve the performance of synchronization procedures, reduce network roundtrips and speed up data replication, you can copy rows with LOBs in larger batches. Configure larger batches only if the instance hosting the replication server has enough memory. From c22653936799a0b6a25653b5be09d3254681045b Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 21 Aug 2024 14:50:07 +0200 Subject: [PATCH 09/17] EPRS: release notes for 7.9.0 --- .../7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx | 31 +++++++++++++++++++ .../docs/eprs/7/eprs_rel_notes/index.mdx | 30 +++++++++--------- 2 files changed, 47 insertions(+), 14 deletions(-) create mode 100644 product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx diff --git a/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx new file mode 100644 index 00000000000..6bf6aabf6f8 --- /dev/null +++ b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx @@ -0,0 +1,31 @@ +--- +title: "Replication Server 7.9.0 release notes" +navTitle: Version 7.9.0 +--- + +Released: 22 Aug 2024 + +New features, enhancements, bug fixes, and other changes in Replication Server 7.9.0 include the following: + +| Type | Description | Addresses | +|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------| +| Enhancement | EDB Postgres Replication Server now supports batch replication for Oracle CLOB and BLOB types in Synchronize mode. This significantly reduces the time required to replicate a large number of row changes containing CLOB/BLOB type columns. | #102185
#35513 | +| Enhancement | The transaction commit timestamp from the origin node is now preserved when replicating to a target node. This is required to process the timestamp-based UPDATE conflicts when EDB Postgres Replication Server is used in a hybrid cluster where the EPRS Publication node is shared with EDB Postgres Distributed (PGD). | | +| Bug fix | Fixed a corner case issue where the synchronization from the target MMR node failed to resume. | #102604
#35539 | +| Bug fix | Fixed an issue where some of the processed entries in the `rrep_tx_monitor` table were not cleaned up. | | + +## End-of-support notice + +We recommend that you update to the most recent software version. +*If you haven't yet updated to the most current version, see the end-of-support notes that follow*: + +**Software:** Replication Server + +**Version:** 6.2 + +**End of Standard Support:** June 1, 2023 + +Additional details can be found at [EDB Platform Compatibility](https://www.enterprisedb.com/resources/platform-compatibility). + +!!! Note + Version 7.x provides a non-breaking upgrade path for existing 6.2.x-based cluster deployments. However, we strongly recommend that the upgrade be verified in a staging or non-production environment before applying the upgrade in a production environment. \ No newline at end of file diff --git a/product_docs/docs/eprs/7/eprs_rel_notes/index.mdx b/product_docs/docs/eprs/7/eprs_rel_notes/index.mdx index bf577a19d45..5cc7b44f0b7 100644 --- a/product_docs/docs/eprs/7/eprs_rel_notes/index.mdx +++ b/product_docs/docs/eprs/7/eprs_rel_notes/index.mdx @@ -3,6 +3,7 @@ title: "Release notes" redirects: - ../01_whats_new/ navigation: + - eprs_rel_notes_7.9.0 - eprs_rel_notes_7.8.0 - eprs_rel_notes_7.7.0 - eprs_rel_notes_7.6.0 @@ -14,20 +15,21 @@ navigation: The Replication Server documentation describes the latest version including minor releases and patches. The release notes in this section provide information on what was new in each release. For new functionality introduced in a minor or patch release, there are also indicators within the content about what release introduced the feature. -| Version | Release Date | -| -------------------------------- | ------------ | -| [7.8.0](eprs_rel_notes_7.8.0) | 17 May 2024 | -| [7.7.0](eprs_rel_notes_7.7.0) | 14 Dec 2023 | -| [7.6.0](eprs_rel_notes_7.6.0) | 07 Sep 2023 | -| [7.5.1](eprs_rel_notes_7.5.1) | 26 May 2023 | -| [7.5.0](eprs_rel_notes_7.5.0) | 14 Feb 2023 | -| [7.4.0](eprs_rel_notes_7.4.0) | 29 Nov 2022 | -| [7.3.0](15_eprs_rel_notes_7.3.0) | 15 Nov 2022 | -| [7.2.1](16_eprs_rel_notes_7.2.1) | 25 Jul 2022 | -| [7.2.0](17_eprs_rel_notes_7.2.0) | 24 Jun 2022 | -| [7.1.0](18_eprs_rel_notes_7.1.0) | 21 Mar 2022 | -| [7.0.1](19_eprs_rel_notes_7.0.1) | 03 Mar 2022 | -| [7.0.0](20_eprs_rel_notes_7.0.0) | 01 Dec 2021 | +| Version | Release Date | +|----------------------------------|--------------| +| [7.9.0](eprs_rel_notes_7.9.0) | 22 Aug 2024 | +| [7.8.0](eprs_rel_notes_7.8.0) | 17 May 2024 | +| [7.7.0](eprs_rel_notes_7.7.0) | 14 Dec 2023 | +| [7.6.0](eprs_rel_notes_7.6.0) | 07 Sep 2023 | +| [7.5.1](eprs_rel_notes_7.5.1) | 26 May 2023 | +| [7.5.0](eprs_rel_notes_7.5.0) | 14 Feb 2023 | +| [7.4.0](eprs_rel_notes_7.4.0) | 29 Nov 2022 | +| [7.3.0](15_eprs_rel_notes_7.3.0) | 15 Nov 2022 | +| [7.2.1](16_eprs_rel_notes_7.2.1) | 25 Jul 2022 | +| [7.2.0](17_eprs_rel_notes_7.2.0) | 24 Jun 2022 | +| [7.1.0](18_eprs_rel_notes_7.1.0) | 21 Mar 2022 | +| [7.0.1](19_eprs_rel_notes_7.0.1) | 03 Mar 2022 | +| [7.0.0](20_eprs_rel_notes_7.0.0) | 01 Dec 2021 | ## Supported upgrade paths From 1475dc9f9f848ae0a63e0f3cac44b7b077b8727f Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 21 Aug 2024 14:52:07 +0200 Subject: [PATCH 10/17] Rephrased Addresses to Tickets following the temrinology that other producst use --- .../docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx index 6bf6aabf6f8..65c14014918 100644 --- a/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx +++ b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx @@ -7,7 +7,7 @@ Released: 22 Aug 2024 New features, enhancements, bug fixes, and other changes in Replication Server 7.9.0 include the following: -| Type | Description | Addresses | +| Type | Description | Ticket | |--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------| | Enhancement | EDB Postgres Replication Server now supports batch replication for Oracle CLOB and BLOB types in Synchronize mode. This significantly reduces the time required to replicate a large number of row changes containing CLOB/BLOB type columns. | #102185
#35513 | | Enhancement | The transaction commit timestamp from the origin node is now preserved when replicating to a target node. This is required to process the timestamp-based UPDATE conflicts when EDB Postgres Replication Server is used in a hybrid cluster where the EPRS Publication node is shared with EDB Postgres Distributed (PGD). | | From b4c5aefad265ef132ddc7833ec05375f4b1bddcb Mon Sep 17 00:00:00 2001 From: nidhibhammar <59045594+nidhibhammar@users.noreply.github.com> Date: Wed, 21 Aug 2024 23:08:57 +0530 Subject: [PATCH 11/17] EPAS 16.4 Release notes fix Updated the correct support ticket number --- .../docs/epas/16/epas_rel_notes/epas16_4_0_rel_notes.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/epas/16/epas_rel_notes/epas16_4_0_rel_notes.mdx b/product_docs/docs/epas/16/epas_rel_notes/epas16_4_0_rel_notes.mdx index 57678f19188..e2cb3fdce51 100644 --- a/product_docs/docs/epas/16/epas_rel_notes/epas16_4_0_rel_notes.mdx +++ b/product_docs/docs/epas/16/epas_rel_notes/epas16_4_0_rel_notes.mdx @@ -14,7 +14,7 @@ EDB Postgres Advanced Server 16.4.0 includes the following enhancements and bug | Bug fix | Fixed an issue for EDB*Loader. Now when multiple duplicate key errors occur during the load it doesn't slow down and memory doesn't overflow. | #37017 | | Bug fix | Fixed an issue for replication connections. Now it correctly displays the authentication failure error message. | #101591 | | Bug fix | Fixed an issue for `ecpg`. Now it supports `do..while()` in Pro*C mode (`-C PROC`). | #35988 | -| Bug fix | Fixed an issue for `edb_dblink_oci`. Now it correctly push downs `ANY` and `ALL` operators when used with scalar array. | #36220 | +| Bug fix | Fixed an issue for `edb_dblink_oci`. Now it correctly push downs `ANY` and `ALL` operators when used with scalar array. | | | Bug fix | Fixed an issue for `to_number()` function. Now it correctly accepts the `"+"` sign. | #92903 | | Bug fix | Fixed an issue with incomplete transactions clean up after a crash. Now the incomplete transactions are cleaned up in reorder buffer after a crash. | #99636 | -| Bug fix | Fixed an issue with `edb_dblink_oci`. Now it uses SHA256 instead of MD5 for password obfuscation. | #86497 | +| Bug fix | Fixed an issue with `edb_dblink_oci`. Now it uses SHA256 instead of MD5 for password obfuscation. | #38240 | From 008d7874219dac3fdb789e19e06264f6a0ba8ef6 Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Thu, 22 Aug 2024 09:01:34 +0200 Subject: [PATCH 12/17] Minor indentation correction. --- .../02_optimize_sync_replication/using_bacth_lob.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx index e6ae9713b4f..84715ba32cf 100644 --- a/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx +++ b/product_docs/docs/eprs/7/05_smr_operation/08_optimizing_performance/02_optimize_sync_replication/using_bacth_lob.mdx @@ -34,4 +34,4 @@ You have upgraded your instances to a Replication Server version that includes t 1. Reload the configuration file as specified in [Reloading the configuration file](../../../08_xdb_cli/03_xdb_cli_commands/52_reload_conf_file). -Now, each time you perform a synchronization, the Replication Server will copy 150 rows with LOB objects per network roundtrip. + Now, each time you perform a synchronization, the Replication Server will copy 150 rows with LOB objects per network roundtrip. From b682b75a15a9895c0c78a6ae5104cdef96a8428a Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Thu, 22 Aug 2024 09:17:15 +0200 Subject: [PATCH 13/17] Implemented feedback from Matt --- .../docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx index 65c14014918..8430aa9b433 100644 --- a/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx +++ b/product_docs/docs/eprs/7/eprs_rel_notes/eprs_rel_notes_7.9.0.mdx @@ -16,8 +16,9 @@ New features, enhancements, bug fixes, and other changes in Replication Server 7 ## End-of-support notice -We recommend that you update to the most recent software version. -*If you haven't yet updated to the most current version, see the end-of-support notes that follow*: +Replication Server 6.2 is no longer a supported version. + +To ensure that your usage of Replication Server is supported, please upgrade any installations with version 6.2 to version 7. See the end-of-support notes that follow: **Software:** Replication Server @@ -28,4 +29,4 @@ We recommend that you update to the most recent software version. Additional details can be found at [EDB Platform Compatibility](https://www.enterprisedb.com/resources/platform-compatibility). !!! Note - Version 7.x provides a non-breaking upgrade path for existing 6.2.x-based cluster deployments. However, we strongly recommend that the upgrade be verified in a staging or non-production environment before applying the upgrade in a production environment. \ No newline at end of file + Version 7.x provides a non-breaking upgrade path for existing 6.2.x-based cluster deployments. However, we strongly recommend that the upgrade be verified in a staging or non-production environment before applying the upgrade in a production environment. From 879c736b3cfab841a1da9f53fe83c3984e839e84 Mon Sep 17 00:00:00 2001 From: tusharahuja <30723619+tusharahuja@users.noreply.github.com> Date: Thu, 22 Aug 2024 13:55:00 +0530 Subject: [PATCH 14/17] Update epas16_3_0_rel_notes.mdx there is a typo , instead of bug - it is Buf written. --- .../docs/epas/16/epas_rel_notes/epas16_3_0_rel_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/epas/16/epas_rel_notes/epas16_3_0_rel_notes.mdx b/product_docs/docs/epas/16/epas_rel_notes/epas16_3_0_rel_notes.mdx index df83316226c..4a7e46d417f 100644 --- a/product_docs/docs/epas/16/epas_rel_notes/epas16_3_0_rel_notes.mdx +++ b/product_docs/docs/epas/16/epas_rel_notes/epas16_3_0_rel_notes.mdx @@ -18,4 +18,4 @@ EDB Postgres Advanced Server 16.3.0 includes the following enhancements and bug | Bug fix | Fixed an crash issue for `edbldr`. Now `edbldr` loads data into multiple tables with different encodings from the target database. | | | Bug fix | Fixed an issue with possible data loss and `pg_dump` failures when using rowids. | #35901 | | Bug fix | Fixed an issue with assertion in `DROP ROLE` statement having duplicate names. | | -| Buf fix | Fixed server crash with `edb_dblink_oci` in left join with whole row reference. | | +| Bug fix | Fixed server crash with `edb_dblink_oci` in left join with whole row reference. | | From 14f639e36439f7633151925bccf5e1c72476f3f9 Mon Sep 17 00:00:00 2001 From: Bobby Bissett <70302203+EFM-Bobby@users.noreply.github.com> Date: Wed, 7 Aug 2024 08:06:06 -0400 Subject: [PATCH 15/17] fix efm auto.allow.hosts property description I think something automated clobbered this, because the descriptive text and the property comment description both were garbled. The descriptive text now makes sense again, though it's a long sentence and I'm open to suggestions. I changed "update" to "set" because there isn't actually a list to update since the cluster doesn't exist before starting this node. Am ok with going back though. --- .../efm/4/04_configuring_efm/01_cluster_properties.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx index bee0578b17a..337002feee4 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx @@ -614,12 +614,12 @@ ping.server.command=/bin/ping -q -c3 -w5 -Use the `auto.allow.hosts` property to instruct the server to use the addresses specified in the `.nodes` file of the first nostarts to update the allowed host list. Enabling this property by setting `auto.allow.hosts` to `true` can simplify cluster startup. +Use the `auto.allow.hosts` property to instruct the server to use the addresses specified in the `.nodes` file of the first node to start to set the allowed host list. Enabling this property by setting `auto.allow.hosts` to `true` can simplify cluster startup. ```ini -# Have the first nostarts automatically add the addresses -# from its .nodes file to the allowed host list. This will make -# it faster to start the cluster when the initial set of hosts +# Have the first node started automatically add the addresses from +# its .nodes file to the allowed host list. This will make it +# faster to start the cluster when the initial set of hosts # is already known. auto.allow.hosts=false ``` From f994d487568e679cc8b23bef487eb4c1f50a54d9 Mon Sep 17 00:00:00 2001 From: nidhibhammar <59045594+nidhibhammar@users.noreply.github.com> Date: Thu, 22 Aug 2024 15:14:39 +0530 Subject: [PATCH 16/17] PgBouncer - 1.23.1.0 release Added 1.23.1.0 release notes --- .../1/pgbouncer_rel_notes/12310_rel_notes.mdx | 12 ++++++++++++ .../docs/pgbouncer/1/pgbouncer_rel_notes/index.mdx | 2 ++ 2 files changed, 14 insertions(+) create mode 100644 product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/12310_rel_notes.mdx diff --git a/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/12310_rel_notes.mdx b/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/12310_rel_notes.mdx new file mode 100644 index 00000000000..9d614e048bb --- /dev/null +++ b/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/12310_rel_notes.mdx @@ -0,0 +1,12 @@ +--- +title: "EDB PgBouncer 1.23.1.0 release notes" +navTitle: Version 1.23.1.0 +--- + +Released: 22 Aug 2024 + +EDB PgBouncer 1.23.1.0 includes the following upstream merge and security fix: + +| Type | Description | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | +| Upstream merge | Merged with community PgBouncer 1.23.1.0. See the community [Release Notes](https://www.pgbouncer.org/changelog.html#pgbouncer-123x) for details. | diff --git a/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/index.mdx b/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/index.mdx index b238727c7de..efef61d6cf6 100644 --- a/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/index.mdx +++ b/product_docs/docs/pgbouncer/1/pgbouncer_rel_notes/index.mdx @@ -3,6 +3,7 @@ title: "Release notes" redirects: - ../01_whats_new/ navigation: + - 12310_rel_notes - 12300_rel_notes - 02_12210_rel_notes - 03_12200_rel_notes @@ -19,6 +20,7 @@ The EDB PgBouncer documentation describes the latest version of EDB PgBouncer 1, | Version | Release date | Upstream merges | | ------------------------------ | ------------ | ---------------------------------------------------------------------------- | +| [1.23.1.0](12310_rel_notes) | 22 Aug 2024 | Upstream [1.23.1.0](https://www.pgbouncer.org/changelog.html#pgbouncer-123x) | | [1.23.0.0](12300_rel_notes) | 01 Aug 2024 | Upstream [1.23.0.0](https://www.pgbouncer.org/changelog.html#pgbouncer-123x) | | [1.22.1.0](02_12210_rel_notes) | 16 Apr 2024 | Upstream [1.22.1.0](https://www.pgbouncer.org/changelog.html#pgbouncer-122x) | | [1.22.0.0](03_12200_rel_notes) | 29 Feb 2024 | Upstream [1.22.0.0](https://www.pgbouncer.org/changelog.html#pgbouncer-122x) | From bc1bbad2fad1ef923e36d91a448d2f8e2204ef9a Mon Sep 17 00:00:00 2001 From: nidhibhammar <59045594+nidhibhammar@users.noreply.github.com> Date: Thu, 22 Aug 2024 20:48:25 +0530 Subject: [PATCH 17/17] EFM - cluster properties update Updated the content as per [DOCS-125](https://enterprisedb.atlassian.net/browse/DOCS-125) --- .../docs/efm/4/04_configuring_efm/01_cluster_properties.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx index 337002feee4..99abec3e4e4 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx @@ -1237,7 +1237,9 @@ lock.dir= -Use the `log.dir` property to specify the location to write agent log files. Failover Manager attempts to create the directory if the directory doesn't exist. +Use the `log.dir` property to specify the location to write agent log files. Failover Manager attempts to create the directory if the directory doesn't exist. The `log.dir` parameter defined in the efm.properties file determines the directory path where the EFM logs are stored. Please note that this parameter applies exclusively to the EFM logs and does not affect the logging configuration for any other components or services. + +To change the startup log location for EFM, you need to modify the `runefm.sh` script located in the EFM's bin directory. Specifically, you can set the `LOG` parameter within this script to define the desired log file location. ```ini # Specify the directory of agent logs on the node. If the path