fixing merge conflict

Author: paulth1

articles/postgresql/migrate/migration-service/best-practices-migration-service-postgresql.md

@@ -53,7 +53,7 @@ The following phases are considered for calculating the total downtime to perfor
 - Matching counts for all the database objects (tables, sequences, extensions, procedures, and indexes).
 - Comparing maximum or minimum IDs of key application-related columns.
 
-    > [!NOTE]  
+    > [!NOTE]
     > The size of databases needs to be the right metric for validation. The source instance might have bloats or dead tuples, which can bump up the size of the source instance. It's normal to have size differences between source instances and target servers. An issue in the first three steps of validation indicates a problem with the migration.
 
 - **Migration of server settings**: Any custom server parameters, firewall rules (if applicable), tags, and alerts must be manually copied from the source instance to the target.
@@ -90,7 +90,7 @@ If the data distribution on the source is highly skewed, with most of the data p
 
 1. The table must have a column with a simple (not composite) primary key or unique index of type int or significant int.
 
-    > [!NOTE]  
+    > [!NOTE]
     > In the case of approaches #2 or #3, you must carefully evaluate the implications of adding a unique index column to the source schema. Only after confirmation that adding a unique index column won't affect the application should you go ahead with the changes.
 
 1. If the table doesn't have a simple primary key or unique index of type int or significant int but has a column that meets the data type criteria, the column can be converted into a unique index by using the following command. This command doesn't require a lock on the table.

articles/postgresql/migrate/migration-service/concepts-user-roles-migration-service.md

@@ -28,7 +28,7 @@ This section explores the differences in permissions granted to the **azure_pg_a
 
 ### PG catalog permissions
 
-Unlike user-created schemas, which organize database objects into logical groups, pg_catalog is a system schema. It houses crucial system-level information, such as details about tables, columns, and other internal bookkeeping data. Essentially, it's where PostgreSQL stores important metadata.
+Unlike user-created schemas, which organize database objects into logical groups, pg_catalog is a system schema. It houses crucial system-level information, such as details about tables, columns, and other internal bookkeeping data. It's where PostgreSQL stores important metadata.
 
 - In a single server environment, a user belonging to the azure_pg_admin role is granted select privileges for all pg_catalog tables and views.
 - In a flexible server environment, privileges are restricted for certain tables and views so that only superusers are allowed to query them.
@@ -57,7 +57,7 @@ We removed all privileges for non-superusers on the following pg_catalog views:
 
 - pg_shadow
 
-Allowing unrestricted access to these system tables and views could lead to unauthorized modifications, accidental deletions, or even security breaches. Festricted access reduces the risk of unintended changes or data exposure.
+Allowing unrestricted access to these system tables and views could lead to unauthorized modifications, accidental deletions, or even security breaches. Restricted access reduces the risk of unintended changes or data exposure.
 
 ### pg_pltemplate deprecation
 
@@ -66,7 +66,7 @@ Another important consideration is the deprecation of the **pg_pltemplate** syst
 #### What is the impact?
 
 - If your application is designed to directly query the affected tables and views, it encounters issues upon migrating to the flexible server. We strongly advise you to refactor your application to avoid direct queries to these system tables.
-- If you have granted or revoked privileges to any users or roles for the affected pg_catalog tables and views, you encounter an error during the migration process. You can identify this error by the following pattern:
+- If you've granted or revoked privileges to any users or roles for the affected pg_catalog tables and views, you encounter an error during the migration process. You can identify this error by the following pattern:
 
 ```sql
 pg_restore error: could not execute query <GRANT/REVOKE> <PRIVILEGES> on <affected TABLE/VIEWS> to <user>.
@@ -120,16 +120,13 @@ REVOKE SELECT ON pg_authid FROM adminuser1;
 REVOKE SELECT ON pg_shadow FROM adminuser2;
 REVOKE UPDATE ON pg_shadow FROM adminuser2;
 ```
-<<<<<<< HEAD
-=======
 
 **Step 4: Final Verification**
 
-Run the query from Step 1 again to ensure that the resulting output set is empty.
+Run the query from step 1 again to ensure that the resulting output set is empty.
 
 > [!NOTE]
-> Make sure you perform the above steps for all the databases included in the migration to avoid any permission-related issues during the migration.
->>>>>>> 650471f5f972debc44f06e7f505345c09d6603d1
+> Make sure you perform the preceding steps for all the databases included in the migration to avoid any permission-related issues during the migration.
 
 > [!NOTE]
 > Make sure you perform the preceding steps for all the databases included in the migration to avoid any permission-related issues during the migration.