On Tue, Jun 17, 2025 at 4:26 PM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.com> wrote: > > On Mon, Jun 16, 2025 at 7:37 PM Amit Kapila wrote: > > > > > > 3. Isn't the new check for logical slots in > > check_new_cluster_subscription_configuration() somewhat redundant with > > the previous check done in check_new_cluster_logical_replication_slots()? > > Can't we combine both? > > Merged as suggested. >
Okay, it is better to update the comments atop check_new_cluster_replication_slots() to reflect the new functionality as well. After the upgrade, there will be a window where the launcher could take the time to create the conflict_slot if there exists any subscription that has retain_conflict_info enabled, and during that window, the update_delete conflicts won't be detected reliably. To close that, we can probably create the conflict_slot during upgrade, if required. Now, because we don't copy commit_ts during upgrade, we still won't be able to detect origin_differ conflicts reliably after upgrade. This can happen in cases where we want to detect conflicts for the transactions that were pending to replicate before the upgrade. Note, we don't ensure that the subscriber receives and apply all the transactions before the upgrade. Similarly, no slot information after the upgrade helps to protect the rows from being vacuumed after the upgrade of the subscriber, so update_delete conflict also may not be detected reliably for the transactions pending before the upgrade. I think we need to mention this in the docs so that users can try to ensure that all pending transactions have been applied before upgrading the subscriber, if they want to detect all possible conflicts reliably. -- With Regards, Amit Kapila.
