Merge pull request #631 from MicrosoftDocs/main

10/22/2024 PM Publish

articles/cosmos-db/mongodb/cosmos-db-vs-mongodb-atlas.md

@@ -43,7 +43,7 @@ ms.date: 02/27/2024
 | Support for MongoDB multi-document ACID transactions | Yes, with [vCore-based Azure Cosmos DB for MongoDB](./vcore/introduction.md) | Yes | 
 | JSON data type support | BSON (Binary JSON) | BSON (Binary JSON) |
 | Support for MongoDB aggregation pipeline | Yes. Supporting MongoDB wire protocol v7, v6, and v5 in vCore and RU architectures.​ | Yes |
-| Maximum document size | 16 MB | 16 MB |
+| Maximum document size | 16 MB in vCore and RU architecture | 16 MB |
 | JSON schema for data governance controls | Currently in development | Yes |
 | Integrated text search | Yes | Yes |
 | Integrated querying of data in cloud object storage | Yes, with Synapse Link | Yes |

articles/cosmos-db/nosql/query/working-with-json.md

@@ -61,22 +61,23 @@ Here's a document with nested JSON:
 
 In this case, the ``sku``, ``colors``, and ``sizes`` properties are all nested within the ``metadata`` property. The ``name`` property is also nested within the ``manufacturer`` property.
 
-This first example projects two nested properties.
+This first example projects three nested properties.
 
 ```nosql
 SELECT
-    p.name,
+    p.manufacturer.name,
     p.metadata.sku,
-    p.sizes.small.inches AS size
+    p.metadata.sizes.small.inches AS size
 FROM
     products p
 ```
 
 ```json
 [
   {
-    "name": "Teapo rainbow surfboard",
-    "sku": "72109"
+    "name": "AdventureWorks",
+    "sku": "72109",
+    "size": 76
   }
 ]
 ```

articles/postgresql/flexible-server/concepts-query-store.md

@@ -1,10 +1,10 @@
 ---
 title: Query Store
 description: This article describes the Query Store feature in Azure Database for PostgreSQL - Flexible Server.
-author: varun-dhawan
-ms.author: varundhawan
+author: nachoalonsoportillo
+ms.author: ialonso
 ms.reviewer: maghan
-ms.date: 07/25/2024
+ms.date: 10/22/2024
 ms.service: azure-database-postgresql
 ms.subservice: flexible-server
 ms.topic: conceptual
@@ -275,9 +275,6 @@ This function discards all statistics gathered so far by Query Store. It discard
 
 This function discards all statistics gathered in-memory by Query Store (that is, the data in memory that hasn't been flushed yet to the on disk tables supporting persistence of collected data for Query Store). This function can only be executed by the server admin role (**azure_pg_admin**).
 
-## Limitations and known issues
-[!INCLUDE [Note Query store and Azure storage compability](includes/note-query-store-azure-storage-compability.md)]
-
 ### Read-only mode
 When an Azure Database for PostgreSQL - Flexible Server instance is in read-only mode, such as when the `default_transaction_read_only` parameter is set to `on`, or if read-only mode is [automatically enabled due to reaching storage capacity](concepts-limits.md#storage), Query Store does not capture any data.
 

articles/postgresql/flexible-server/includes/server-parameters-azure-notes-max-wal-senders.md

@@ -0,0 +1,28 @@
+---
+title: max_wal_senders server parameter
+description: max_wal_senders server parameter for Azure Database for PostgreSQL - Flexible Server.
+ms.service: azure-database-postgresql
+ms.subservice: flexible-server
+ms.topic: include
+ms.date: 10/14/2024
+author: nachoalonsoportillo
+ms.author: ialonso
+zone_pivot_groups: postgresql-server-version
+---
+#### Azure-specific notes
+The default value for the `max_wal_senders` server parameter set when you provision the instance of Azure Database for PostgreSQL flexible server must never be decreased below `2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication`.
+
+When considering the need to increase `max_wal_senders` to a much higher value to be able to cope with the logical replication of a substantial number of tables, have the following important points in mind:
+
+- Logically replicating a large number of tables doesn't necessarily need a large number of WAL senders.
+- The only reason why you need separate WAL sender per-table or group of tables is if you need separate subscriptions for each of those tables or groups of.
+- Whatever number of WAL senders are being utilized for physical and logical replication, they all become active at once, whenever any backend writes something to the write-ahead log. When that happens, the WAL senders that are assigned to do logical replication all wake up to:
+    1. Decode all new records in the WAL, 
+    1. Filter out log records they're not interested in,
+    1. Replicate the data that's relevant to each of them. 
+- WAL senders are similar to connections in the sense that, if they are idle, it doesn't matter how many there are. However, if they are active, they'll just compete for the same resources and the performance could end up being terribly bad. This is especially true for senders with logical replication, because the logical decoding is rather CPU expensive. Each worker has to decode the entire WAL, even if it only replicates the operations affecting a single table, and that represents a tiny percentage of all the data in the write-ahead log. For physical replication it's not that important, because the WAL senders don't consume CPU so intensively, and they tend to be bounded by network bandwidth first.
+- Therefore, in general, it's better to not have many more WAL senders than vCores.
+- It's a good practice to add room for a few extra WAL senders to accommodate future growth or temporary spikes in replication connections. The following two examples might help illustrate it better.
+    - For a server with 8 vCores, HA disabled, 2 read replicas, and 3 logical replication slots, you may want to configure `max_wal_senders` as the sum of physical slots for HA (0) + physical slots for read replicas (2) + logical slots(3) + some extra for future growth, considering available vCores (1) = **6**.
+    - For a server with 16 vCores, HA enabled, 4 read replicas, and 5 logical replication slots, you may want to configure `max_wal_senders` as the sum of physical slots for HA (2) + physical slots for read replicas (4) + logical slots(5) + some extra for future growth, considering available vCores (2) = **13**.
+- If you still consider that the maximum value allowed for this parameter is too low for your needs, please [contact us](../overview.md#contacts), describe your scenario in detail and explain what do you consider that would be the minimum acceptable value you would need for your scenario to perform properly.

articles/postgresql/flexible-server/includes/server-parameters-table-11-replication-sending-servers.md

@@ -37,7 +37,7 @@ ms.topic: include
 | Documentation  | [max_wal_senders](https://www.postgresql.org/docs/11/runtime-config-replication.html#GUC-MAX-WAL-SENDERS)               |
 
 
-[!INCLUDE [server-parameters-azure-notes-void](./server-parameters-azure-notes-void.md)]
+[!INCLUDE [server-parameters-azure-notes-max-wal-senders](./server-parameters-azure-notes-max-wal-senders.md)]
 
 
 

articles/postgresql/flexible-server/includes/server-parameters-table-11-reporting-and-logging-what-to-log.md

@@ -134,8 +134,8 @@ ms.topic: include
 | Description    | Causes each attempted connection to the server to be logged, as well as successful completion of client authentication. |
 | Data type      | boolean     |
 | Default value  | `on`          |
-| Allowed values | `on`                    |
-| Parameter type | read-only      |
+| Allowed values | `on,off`                |
+| Parameter type | dynamic        |
 | Documentation  | [log_connections](https://www.postgresql.org/docs/11/runtime-config-logging.html#GUC-LOG-CONNECTIONS)                   |
 
 
@@ -151,8 +151,8 @@ ms.topic: include
 | Description    | Logs end of a session, including duration.                                                                              |
 | Data type      | boolean     |
 | Default value  | `on`          |
-| Allowed values | `on`                    |
-| Parameter type | read-only      |
+| Allowed values | `on,off`                |
+| Parameter type | dynamic        |
 | Documentation  | [log_disconnections](https://www.postgresql.org/docs/11/runtime-config-logging.html#GUC-LOG-DISCONNECTIONS)             |