Hi Ajin, > Thanks for your comments, I agree with all your comments and have > addressed them in v19.
Thanks for updating the patch. I requested my LLM to review your patch set, It found a possible issue, when the source is PG16-.. Do you think it should be fixed? If the source node is PG16-, the apply worker can start even during the pg_upgrade command. So, it may be possible that the replication origin can be go backward with the below steps: 1. the pg_dumpall command reads the remote_lsn from the old source. the value is LSN_1. 2. the apply worker on the old source receives and applies changes. 3. the worker also updates the replication origin. The value is LSN_2. 4. then the source is stopped and heap is copied by the pg_upgrade command. The data is replicated till LSN_2, but the remote_lsn would be LSN_1. 5. the apply worker requests replicating data from LSN_1. It's not problematic if the confirmed_flush has already been updated to LSN_2 on publisher side, the publisher ignores the requested startpoint (LSN_1) and starts for LSN_2. remote_lsn can be eventually corrected. If not replicated yet, the publisher may send the same data thus can cause the data duplication error. But IIUC it seems possible even for HEAD. The apply worker does not request the specific startpoint (i.e., 0/0), and the walsender replicates after the confirmed_flush. To the end, the outcome is mostly the same, but origin may show the wrong value for a while. Best regards, Hayato Kuroda FUJITSU LIMITED
