Commit
8e0d32a4a1 fixed an issue by allowing the replication origin to be
created while marking the table sync state as SUBREL_STATE_DATASYNC.
Update the comment in check_old_cluster_subscription_state() to accurately
describe this corrected behavior.
Author: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Backpatch-through: 17, where the code was introduced
Discussion: https://postgr.es/m/CAA4eK1+KaSf5nV_tWy+SDGV6MnFnKMhdt41jJjSDWm6yCyOcTw@mail.gmail.com
Discussion: https://postgr.es/m/aUTekQTg4OYnw-Co@paquier.xyz
* states listed below are not supported:
*
* a) SUBREL_STATE_DATASYNC: A relation upgraded while in this state would
- * retain a replication slot, which could not be dropped by the sync
- * worker spawned after the upgrade because the subscription ID used for
- * the slot name won't match anymore.
+ * retain a replication slot and origin. The sync worker spawned after the
+ * upgrade cannot drop them because the subscription ID used for the slot
+ * and origin name no longer matches.
*
* b) SUBREL_STATE_SYNCDONE: A relation upgraded while in this state would
* retain the replication origin when there is a failure in tablesync