diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index f0e0b11678c..9bf347e2caa 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -50,22 +50,26 @@
  * the file we desired across multiple stream-open calls for the same
  * transaction.
  *
- * TWO_PHASE COMMIT TRI-STATE LOGIC
- * --------------------------------
- * By sad timing of apply/tablesync workers it was previously possible to have a
- * prepared transaction that arrives at the apply worker when the tablesync is
- * busy doing the initial sync. In this case, the apply worker does the begin
- * prepare ('b') but it skips all the prepared operations [e.g. inserts] while
- * the tablesync was still busy (see the condition of
- * should_apply_changes_for_rel).
+ * TWO_PHASE TRANSACTIONS
+ * ----------------------
+ * Two phase trasnactions are replayed at prepare and then committed or
+ * rollbacked at commit prepared and rollback prepared respectively. It is
+ * possible to have a prepared transaction that arrives at the apply worker
+ * when the tablesync is busy doing the initial copy. In this case, the apply
+ * worker skips all the prepared operations [e.g. inserts] while the tablesync
+ * was still busy (see the condition of should_apply_changes_for_rel). The
+ * tablesync worker might not get such a prepared transaction because say it
+ * 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
+ * an "empty prepare", because later when the apply worker does the commit
+ * prepare, there is nothing in it (the inserts were skipped earlier).
  *
- * This would lead to an "empty prepare", because later when the apply worker
- * does the commit prepare ('K'), there is nothing in it (the inserts were
- * skipped earlier).
- *
- * To avoid this, and similar prepare confusions the subscription two-phase
- * commit is now implemented as a tri-state with values DISABLED, PENDING, and
- * ENABLED
+ * To avoid this, and similar prepare confusions the subscription two_phase
+ * commit is enabled only after the initial sync is over. The two_phase option
+ * has been implemented as a tri-state with values DISABLED, PENDING, and
+ * ENABLED.
  *
  * Even if the user specifies they want a subscription with two_phase = on,
  * internally it will start with a tri-state of PENDING which only becomes
@@ -80,17 +84,28 @@
  * process_sync_tables_for_apply.
  *
  * When the (re-started) apply worker finds that all tablesyncs are READY for a
- * two_phase tri-state of PENDING it calls wal_startstreaming to *properly*
- * enable the publisher for two-phase commit and updates the tri-state value
- * PENDING -> ENABLED.
+ * two_phase tri-state of PENDING it calls wal_startstreaming to enable the
+ * publisher for two-phase commit and updates the tri-state value
+ * PENDING -> ENABLED. Now, it is possible that during the time we have not
+ * enable two_phase, the publisher (replication server) would have skipped some
+ * prepares but we ensure that such prepares are sent along with commit
+ * prepare, see ReorderBufferFinishPrepared.
  *
  * If ever a user needs to be aware of the tri-state value, they can fetch it
  * from the pg_subscription catalog (see column subtwophase).
  *
- * Finally, to avoid problems from any subsequent (not READY) tablesyncs
- * interfering with the messages (same as the original problem) there is a
- * restriction for ALTER SUBSCRIPTION REFRESH  PUBLICATION. This command is not
- * permitted for two_phase = on, except when copy_data = false.
+ * We don't allow to toggle two_phase option of a subscription because it can
+ * lead to the inconsistent replica. Consider, initially, it was on and we have
+ * received some prepare then we turn it off, now at commit time the server
+ * will send the entire transaction data along with the commit. With some more
+ * analysis, we can allow changing this option from off to on but not sure if
+ * that alone would be useful.
+ *
+ * Finally, to avoid problems mentioned in previous paragraphs from any
+ * subsequent (not READY) tablesyncs (need to toggle two_phase option from 'on'
+ * 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.
  *-------------------------------------------------------------------------
  */