RE: [PATCH] Preserve replication origin OIDs in pg_upgrade

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