Merge pull request #4731 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-09 22:06 UTC

Author: learn-build-service-prod[bot]

articles/mysql/flexible-server/release-notes/march-2026.md

@@ -33,6 +33,7 @@ This version doesn't introduce any new features.
 
 - Returns clear, actionable customer‑facing errors for invalid key scenarios, improving troubleshooting and support experience.
 - Enables self‑service configuration of binlog_row_metadata, unblocking CDC/Data Out integrations and reducing support dependency.
+- As part of the March 2026 update, the daily automated backup time for your server is expected to change once. After this update, backups will continue to run once, every day as usual. Daily automatic backup continues unchanged and only the scheduled time of the daily backup shifts once. No user action is required.
 
 ## Known issues fixes
 

articles/postgresql/configure-maintain/concepts-major-version-upgrade.md

@@ -4,7 +4,7 @@ description: Learn how to use Azure Database for PostgreSQL to do in-place major
 author: varun-dhawan
 ms.author: varundhawan
 ms.reviewer: maghan
-ms.date: 3/23/2026
+ms.date: 4/8/2026
 ms.service: azure-database-postgresql
 ms.subservice: configuration
 ms.topic: concept-article
@@ -22,7 +22,7 @@ Your Azure Database for PostgreSQL flexible server instance has a feature that p
 In-place upgrades retain the server name and other settings of the current server after the upgrade of a major version. They don't require data migration or changes to the application connection strings. In-place upgrades are faster and involve shorter downtime than data migration.
 
 > [!NOTE]
-> Azure Database for PostgreSQL supports in-place major version upgrades only to currently supported PostgreSQL versions. For example, you can upgrade the current version given the target version is officially supported by Azure at the time of the upgrade. Unsupported versions can't be selected as upgrade targets, and attempting to upgrade to a deprecated version may result in failure or service disruption. Always consult the [Azure PostgreSQL versioning policy](/azure/postgresql/flexible-server/concepts-version-policy) and [upgrade documentation](/azure/postgresql/flexible-server/concepts-major-version-upgrade) before initiating a major version upgrade. 
+>  Azure Database for PostgreSQL supports in-place major version upgrades only to currently supported PostgreSQL versions. The target version must be officially supported by Azure at the time of the upgrade. The Azure portal prevents selecting unsupported versions, but API or CLI calls that target a deprecated version will fail. Always consult the [Azure PostgreSQL versioning policy](/azure/postgresql/flexible-server/concepts-version-policy) and [upgrade how-to guide](/azure/postgresql/flexible-server/how-to-perform-major-version-upgrade) before initiating a major version upgrade. 
 
 ## Upgrade Process
 
@@ -59,7 +59,7 @@ If a precheck operation fails during an in-place major version upgrade, the upgr
 ### Extension Limitations
 
 In-place major version upgrades do not support all PostgreSQL extensions. The upgrade will fail during the precheck if unsupported extensions are found.
-- The following extensions are supported for regular use, **but will block an in-place major version upgrade if present**. Remove them before the upgrade and re-enable them after, if supported on the target version: `timescaledb`, `postgres_fdw`.
+- The following extensions are supported for regular use, **but will block an in-place major version upgrade if present**. Remove them before the upgrade and re-enable them after, if supported on the target version: `timescaledb`, `postgres_fdw`, `session_variable`, `pg_hint_plan`, `plv8`.
 - The following extensions are **non-persistent utility extensions** and will need to be dropped and re-created after the upgrade by design: `pg_repack`, `hypopg`.
 - When upgrading to PostgreSQL 17 and above, the following extensions are **not supported** and must be removed before upgrade. You may re-enable them only if supported on the target version: `age`, `azure_ai`, `hll`, `pg_diskann`, `pgrouting`.
 

articles/postgresql/high-availability/concepts-high-availability.md

@@ -4,7 +4,7 @@ description: This article describes high availability on an Azure Database for P
 author: gaurikasar
 ms.author: gkasar
 ms.reviewer: maghan
-ms.date: 03/23/2026
+ms.date: 04/09/2026
 ms.service: azure-database-postgresql
 ms.subservice: high-availability
 ms.topic: how-to
@@ -140,12 +140,6 @@ For a detailed guide on configuring and interpreting HA health statuses, see [Hi
 
 - Planned events such as scale computing and scale storage happen on the standby first and then on the primary server. Currently, the server doesn't fail over for these planned operations.
 
-- If you configure logical decoding or logical replication on an HA-enabled flexible server: 
-    - In **PostgreSQL 16** and earlier, logical replication slots aren't preserved on the standby server after a failover by default.
-    - To ensure logical replication continues to function after failover, you need to enable the `pg_failover_slots` extension and configure supporting settings such as `hot_standby_feedback = on`.
-    - Starting with **PostgreSQL 17**, slot synchronization is supported natively. If you enable the correct PostgreSQL configurations (`sync_replication_slots`, `hot_standby_feedback`), logical replication slots are preserved automatically after failover, and no extension is required.
-    - For setup steps and prerequisites,  refer to the [PG_Failover_Slots extension](../extensions/concepts-extensions-versions.md#pg_failover_slots) documentation.
-
 - Configuring availability zones between private (virtual network) and public access with private endpoints isn't supported. You must configure availability zones within a virtual network (spanned across availability zones within a region) or public access with private endpoints.
 
 - You can only configure availability zones within a single region. You can't configure availability zones across regions.
@@ -290,3 +284,39 @@ After a PostgreSQL failover, maintaining optimal database performance involves u
 In contrast, the `pg_stat_*` views, provide runtime activity statistics such as the number of scans, tuples read, and updates, are stored in memory and reset upon failover. An example is `pg_stat_user_tables`, which tracks activity for user-defined tables. This reset accurately reflects the new primary's operational state but also means the loss of historical activity metrics that could inform the autovacuum process and other operational efficiencies.
 
 Given this distinction, you may consider running `ANALYZE` after a PostgreSQL failover. This action updates the `pg_stat_*` data (e.g., `pg_stat_user_tables`) with fresh vacuum activity statistics, helping the autovacuum process, which in turn, ensures that the database performance remains optimal in its new role. This proactive step bridges the gap between preserving essential optimizer statistics and refreshing activity metrics to align with the database's current state.
+
+## Logical replication support with HA
+When using logical replication or logical decoding with High Availability (HA) in Azure Database for PostgreSQL Flexible Server, it’s important to understand how replication slots behave during failover and how to ensure continuity of replication.
+
+### PostgreSQL 16 and earlier
+In PostgreSQL 16 and earlier, logical replication slots aren't automatically preserved on the standby server after a failover. To maintain logical replication across failover, you must:
+- Enable the `pg_failover_slots` extension
+- Configure required settings such as:
+  - `hot_standby_feedback = on`
+
+Without these configurations, logical replication might stop working after a failover because replication slots aren't available on the new primary.
+
+### PostgreSQL 17 and later
+Starting with PostgreSQL 17, logical replication slot synchronization is supported natively. When correctly configured, replication slots are automatically synchronized to the standby server.
+
+To enable this behavior:
+- Set `sync_replication_slots = on`
+- Set `hot_standby_feedback = on`
+
+With these settings, logical replication slots are preserved during failover, and replication can continue without requiring extensions. For details,  refer to the [PG_Failover_Slots extension](../extensions/concepts-extensions-versions.md#pg_failover_slots) documentation.
+
+### Important considerations
+- Logical replication slots are managed on the primary server, but **must also exist** on the standby to ensure logical replication continues after HA failover.
+- System views (for example, querying `pg_replication_slots`) only show the state on the primary and don't confirm whether slots are synchronized to the standby. A system can appear healthy on the primary but still not be failover-ready to preserve logical replication slots on the standby.
+
+### Monitor logical replication failover readiness
+To help validate failover readiness, you can use the Azure Monitor metric `logical_replication_slot_sync_status` (Preview).
+
+This metric indicates whether logical replication slots are synchronized between the HA primary and standby:
+- `1` indicates that slots are synchronized across primary and standby.
+- `0` indicates that slots aren't synchronized on the standby.
+
+If the metric value is 0, logical replication might continue to function on the current primary, but it might not continue after a failover. For more details, refer to the [Logical replication monitoring](../monitor/concepts-monitoring.md#logical-replication).
+
+> [!NOTE]
+> This synchronization state reflects the status across HA nodes and can't be verified using system views on the primary alone. Consider using this metric with alerts to detect when logical replication isn't failover-ready, especially before planned maintenance or failover events. Consider configuring alerts when this metric remains 0 for a sustained period.

articles/postgresql/monitor/concepts-monitoring.md

@@ -4,7 +4,7 @@ description: Review the monitoring and metrics features in an Azure Database for
 author: varun-dhawan
 ms.author: varundhawan
 ms.reviewer: maghan
-ms.date: 04/06/2026
+ms.date: 04/08/2026
 ms.service: azure-database-postgresql
 ms.subservice: monitoring
 ms.topic: concept-article
@@ -111,7 +111,7 @@ Choose from the following categories of enhanced metrics:
 | Display name | Metric ID | Unit | Description | Dimension | Default enabled |
 | --- | --- | --- | --- | --- | --- |
 | **Max Logical Replication Lag** | `logical_replication_delay_in_bytes` | Bytes | Maximum lag across all logical replication slots. | Doesn't apply | Yes |
-| **Logical replication slot sync status (preview)** | `logical_replication_slot_sync_status` | Count | Displays the status of logical replication slot in HA configuration. | Logical Replication Slot | No |
+| **Logical replication slot sync status (preview)** | `logical_replication_slot_sync_status` | Count | Indicates whether logical replication slots are synchronized across High Availability (HA) primary and standby.<br><br>**1** → Slots are synchronized across primary and standby.<br>**0** → Slots are not synchronized on the standby. | Logical Replication Slot | No |
 
 ##### Read Replication