Merge pull request #245650 from AlicjaKucharczyk/patch-1

Update concepts-logical.md

Author: v-dirichards

articles/postgresql/flexible-server/concepts-logical.md

@@ -37,23 +37,23 @@ Logical decoding:
 * Extracts changes across all tables in a database.
 
 
-## Pre-requisites for logical replication and logical decoding
+## Prerequisites for logical replication and logical decoding
 
 1. Go to server parameters page on the portal.
 2. Set the server parameter `wal_level` to `logical`.
 3. If you want to use pglogical extension, search for the `shared_preload_libraries`, and `azure.extensions` parameters, and select `pglogical` from the drop-down box.
 4. Update `max_worker_processes` parameter value to at least 16. Otherwise, you may run into issues like `WARNING: out of background worker slots`.
-5. Save the changes and restart the server to apply the `wal_level` change.
+5. Save the changes and restart the server to apply the changes.
 6. Confirm that your PostgreSQL instance allows network traffic from your connecting resource.
 7. Grant the admin user replication permissions.
    ```SQL
    ALTER ROLE <adminname> WITH REPLICATION;
    ```
-8. You may want to make sure the role you are using has [privileges](https://www.postgresql.org/docs/current/sql-grant.html) on the schema that you're replicating. Otherwise, you may run into errors such as `Permission denied for schema`. 
+8. You may want to make sure the role you're using has [privileges](https://www.postgresql.org/docs/current/sql-grant.html) on the schema that you're replicating. Otherwise, you may run into errors such as `Permission denied for schema`. 
 
 
 >[!NOTE]
-> It is always a good practice to separate your replication user from regular admin account.
+> It's always a good practice to separate your replication user from regular admin account.
 
 ## Using logical replication and logical decoding
 
@@ -92,7 +92,7 @@ Here's some sample code you can use to try out logical replication.
    ```
    You can add more rows to the publisher's table and view the changes on the subscriber.
 
-   If you are not able to see the data, enable the login privilege for `azure_pg_admin` and check the table content. 
+   If you're not able to see the data, enable the login privilege for `azure_pg_admin` and check the table content. 
    ```SQL 
    ALTER ROLE azure_pg_admin login;
    ```
@@ -102,7 +102,7 @@ Visit the PostgreSQL documentation to understand more about [logical replication
 
 ### pglogical extension
 
-Here is an example of configuring pglogical at the provider database server and the subscriber. Refer to [pglogical extension documentation](https://github.com/2ndQuadrant/pglogical#usage) for more details. Also make sure you have performed pre-requisite tasks listed above.
+Here is an example of configuring pglogical at the provider database server and the subscriber. Refer to [pglogical extension documentation](https://github.com/2ndQuadrant/pglogical#usage) for more details. Also make sure you have performed prerequisite tasks listed above.
 
 1. Install pglogical extension in the database in both the provider and the subscriber database servers.
     ```SQL
@@ -221,7 +221,7 @@ In the example below, we use the SQL interface with the wal2json plugin.
    }
    ```
 
-4. Drop the slot once you are done using it.
+4. Drop the slot once you're done using it.
    ```SQL
    SELECT pg_drop_replication_slot('test_slot'); 
    ```
@@ -230,17 +230,17 @@ Visit the PostgreSQL documentation to understand more about [logical decoding](h
 
 
 ## Monitoring
-You must monitor logical decoding. Any unused replication slot must be dropped. Slots hold on to Postgres WAL logs and relevant system catalogs until changes have been read. If your subscriber or consumer fails or if it is improperly configured, the unconsumed logs will pile up and fill your storage. Also, unconsumed logs increase the risk of transaction ID wraparound. Both situations can cause the server to become unavailable. Therefore, it is critical that logical replication slots are consumed continuously. If a logical replication slot is no longer used, drop it immediately.
+You must monitor logical decoding. Any unused replication slot must be dropped. Slots hold on to Postgres WAL logs and relevant system catalogs until changes have been read. If your subscriber or consumer fails or if it's improperly configured, the unconsumed logs will pile up and fill your storage. Also, unconsumed logs increase the risk of transaction ID wraparound. Both situations can cause the server to become unavailable. Therefore, it's critical that logical replication slots are consumed continuously. If a logical replication slot is no longer used, drop it immediately.
 
-The 'active' column in the pg_replication_slots view will indicate whether there is a consumer connected to a slot.
+The 'active' column in the pg_replication_slots view will indicate whether there's a consumer connected to a slot.
 ```SQL
 SELECT * FROM pg_replication_slots;
 ```
 [Set alerts](howto-alert-on-metrics.md) on the **Maximum Used Transaction IDs** and **Storage Used** flexible server metrics to notify you when the values increase past normal thresholds. 
 
 ## Limitations
 * **Logical replication** limitations apply as documented [here](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
-* **Slots and HA failover** - Logical replication slots on the primary server are not available on the standby server in your secondary AZ. This situation applies to you if your server uses the zone-redundant high availability option. In the event of a failover to the standby server, logical replication slots will not be available on the standby.
+* **Slots and HA failover** - Logical replication slots on the primary server aren't available on the standby server in your secondary AZ. This situation applies to you if your server uses the zone-redundant high availability option. In the event of a failover to the standby server, logical replication slots won't be available on the standby.
 
 >[!IMPORTANT]
 > You must drop the logical replication slot in the primary server if the corresponding subscriber no longer exists.  Otherwise the WAL files start to get accumulated in the primary filling up the storage. If the storage threshold exceeds certain threshold and if the logical replication slot is not in use (due to non-available subscriber), Flexible server automatically drops that unused logical replication slot. That action releases accumulated WAL files and avoids your server becoming unavailable due to storage getting filled situation.