diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index 9bf347e2caa..ee3eb56d826 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -62,7 +62,7 @@
  * was prior to the initial consistent point but might have got some later
  * commits. Now, the tablesync worker will exit without doing anything for the
  * prepared transaction skipped by the apply worker as the sync location for it
- * will be already ahead apply worker's current location.  This would lead to
+ * will be already ahead apply worker's current location. This would lead to
  * an "empty prepare", because later when the apply worker does the commit
  * prepare, there is nothing in it (the inserts were skipped earlier).
  *
@@ -106,6 +106,16 @@
  * to 'off' and then again back to 'on') there is a restriction for
  * ALTER SUBSCRIPTION REFRESH PUBLICATION. This command is not permitted for
  * two_phase = on, except when copy_data = false.
+ *
+ * We can get prepare of the same GID more than once for the genuine cases
+ * where we have defined multiple subscriptions for publications on the same
+ * server and prepared transaction has operations on tables subscribed to those
+ * subscriptions. For such cases, one of the prepare will be successful and
+ * others will fail in which case the server will send them again. Once the
+ * commit prepared is done for the first one, the next prepare will be
+ * successful. We have thought of appending some unique identifier (like subid)
+ * with GID but that won't work for cascaded standby setup as the GID can
+ * become too long.
  *-------------------------------------------------------------------------
  */