Merge pull request #273070 from hariramt/task/OnlineUpdate-23April

Online update - 23rd april

Author: prmerger-automator[bot]

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

@@ -70,7 +70,7 @@ The following table gives an overview of offline and online options.
 | Option | PROs | CONs | Recommended For
 |------|------|------|------|
 | Offline | - Simple, easy, and less complex to execute.<br />- Very fewer chances of failure.<br />- No restrictions regarding database objects it can handle | Downtime to applications. | - Best for scenarios where simplicity and a high success rate are essential.<br>- Ideal for scenarios where the database can be taken offline without significant impact on business operations.<br>- Suitable for  databases when the migration process can be completed within a planned maintenance window. |
-| Online | - Very minimal downtime to application. <br /> - Ideal for large databases and customers having limited downtime requirements. | - Replication used in online migration has multiple [restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) (for example, Primary Keys needed in all tables). <br /> - Tough and more complex to execute than offline migration. <br /> - Greater chances of failure due to the complexity of migration. <br /> - There's an impact on the source instance's storage and computing if the migration runs for a long time. The impact needs to be monitored closely during migration. | - Best suited for businesses where continuity is critical and downtime must be kept to an absolute minimum.<br>- Recommended for databases when the migration process needs to occur without interrupting ongoing operations. |
+| Online | - Very minimal downtime to application. <br /> - Ideal for large databases and customers having limited downtime requirements. | - Replication used in online migration has a few [restrictions](https://pgcopydb.readthedocs.io/en/latest/ref/pgcopydb_follow.html#pgcopydb-follow) (for example, Primary Keys needed in all tables). <br /> - Tough and more complex to execute than offline migration. <br /> - Greater chances of failure due to the complexity of migration. <br /> - There's an impact on the source instance's storage and computing if the migration runs for a long time. The impact needs to be monitored closely during migration. | - Best suited for businesses where continuity is critical and downtime must be kept to an absolute minimum.<br>- Recommended for databases when the migration process needs to occur without interrupting ongoing operations. |
 
 The following table lists the various sources supported by the migration service.
 

articles/postgresql/migrate/migration-service/includes/prerequisites/prerequisites-migration-service-postgresql-online.md

@@ -17,14 +17,6 @@ Before you start your migration with migration service in Azure Database for Pos
 
 Source PostgreSQL version should be `>= 9.5`. If the source PostgreSQL version is less than `9.5`, upgrade the source PostgreSQL version to `9.5` or higher before migration.
 
-### Target setup
-
-- Azure Database for PostgreSQL must be set up in Azure before migration.
-
-- The SKU chosen for the Azure Database for PostgreSQL should correspond with the specifications of the source database to ensure compatibility and adequate performance.
-
-- For detailed instructions on creating a new Azure Database for PostgreSQL, refer to the following link: [Quickstart: Create server](/azure/postgresql/flexible-server/).
-
 ### Set up Online migration parameters
 
 For Online migration, the replication support should be set to Logical under replication settings of the source PostgreSQL server. In addition, the server parameters `max_wal_senders` and `max_replication_slots` values should be equal to the number of Databases that need to be migrated. They can also be configured in the command line using the following commands:
@@ -33,11 +25,21 @@ For Online migration, the replication support should be set to Logical under rep
 - ALTER SYSTEM SET max_wal_senders = `number of databases to migrate`;
 - ALTER SYSTEM SET max_replication_slots = `number of databases to migrate`;
 
-You'll need to restart the source PostgreSQL server after completing all the Online migration prerequisites.
+Ensure that there are no long running transactions. Long running transactions don't allow creation of replication slots. The creation of a replication slot will succeed if all long running transactions are committed or rolled-back. You'll need to restart the source PostgreSQL server after completing all the Online migration prerequisites.
 
 > [!NOTE]
 > For online migration with Azure Database for PostgreSQL single server, the Azure replication support is set to logical under the replication settings of the single server page in the Azure portal.
 
+### Target setup
+
+- Azure Database for PostgreSQL must be set up in Azure before migration.
+
+- The SKU chosen for the Azure Database for PostgreSQL should correspond with the specifications of the source database to ensure compatibility and adequate performance.
+
+- For detailed instructions on creating a new Azure Database for PostgreSQL, refer to the following link: [Quickstart: Create server](/azure/postgresql/flexible-server/).
+
+- The `pg_replication_origin` parameter on the target should be at least (1 + `number of databases to migrate`) onto the target.
+
 ### Network setup
 
 Proper networking setup is essential to ensure successful connectivity between the source and target during migration. Here's a guide to help you establish the network connection for different scenarios: