<div><div>Hello.</div><div> </div><div>Thanks for updating the patch. I am using a translator and will not be able to edit the documentation and comments correctly.</div><div> </div></div><div> </div><div>----------------</div><div>Кому: 'Amit Kapila' (amit(dot)kapila16(at)gmail(dot)com);</div><div>Копия: pgsql-hackers(at)postgresql(dot)org, orlovmg(at)gmail(dot)com;</div><div>Тема: Patch for migration of the pg_commit_ts directory;</div><div>23.02.2026, 09:41, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>:</div><blockquote><p>Dear Amit,<br /> </p><blockquote> > Right, and code comments [a] should be also updated.<br /> ><br /> <br /> So, leaving aside update_delete, copying commit_ts could be helpful to<br /> detect some other conflicts. You may want to once test the same and<br /> show it here as part of use case establishment.</blockquote><p><br />I confirmed that {update|delete}_origin_differs could be detected with the<br />following steps.<br /><br />0.<br />Constructed pub-sub replication system. track_commit_timestamp=on was set on the<br />subscriber, and the table below was defined on both clusters<br /><br />```<br /> Table "public.employee"<br /> Column | Type | Collation | Nullable | Default<br />--------+---------+-----------+----------+---------<br /> id | integer | | not null |<br /> salary | integer | | |<br />Indexes:<br /> "employee_pkey" PRIMARY KEY, btree (id)<br />```<br /><br /><br />1.<br />Inserted a tuple on the publisher<br /><br />```<br />pub=# INSERT INTO employee VALUES (1, 100);<br />INSERT 0 1<br />```<br /><br />2.<br />UPDATEd the replicated tuple on the subscriber. Confirmed that commit timestamps<br />were stored.<br /><br />```<br />sub=# SELECT * FROM pg_last_committed_xact();<br /> xid | timestamp | roident<br />-----+-------------------------------+---------<br /> 738 | 2026-02-23 13:17:19.263146+09 | 1<br />(1 row)<br />sub=# UPDATE employee SET salary = 10 WHERE id = 1;<br />UPDATE 1<br />sub=# SELECT * FROM pg_last_committed_xact();<br /> xid | timestamp | roident<br />-----+-------------------------------+---------<br /> 739 | 2026-02-23 13:17:33.230773+09 | 0<br />(1 row)<br />```<br /><br />3.<br />Ran pg_upgrade to upgrade the subscriber. The new cluster must also set<br />track_commit_timestamp to on.<br /><br />4.<br />Confirmed commit timestamps could be migrated.<br /><br />```<br />new=# SELECT * FROM pg_xact_commit_timestamp_origin('739');<br /> timestamp | roident<br />-------------------------------+---------<br /> 2026-02-23 13:17:33.230773+09 | 0<br />(1 row)<br />```<br /><br />5.<br />UPDATEd the tuple on the publisher.<br /><br />```<br />pub=# UPDATE employee SET salary = 200 WHERE id = 1;<br />UPDATE 1<br />```<br /><br />6.<br />update_origin_differs conflict was detected on the new subscriber.<br /><br />```<br />LOG: conflict detected on relation "public.employee": conflict=update_origin_differs<br />DETAIL: Updating the row that was modified locally in transaction 739 at 2026-02-23 13:17:33.230773+09: local row (1, 10), remote row (1, 200), replica identity (id)=(1).<br />CONTEXT: processing remote data for replication origin "pg_16402" during message type "UPDATE" for replication target relation "public.employee" in transaction 745, finished at 0/018A4C6<br />```<br /><br />One debatable point is whether we should include this in the TAP test. Personally<br />It's not necessary to simplify the test; either one is OK.<br /><br /><br />Not sure it is OK, but I created updated patches and considered a commit message.<br />0001 was not changed from the original, and 0002 addressed comments from you and<br />contained the commit message. For now I added my name as one of the author, but<br />OK to be listed as reviewer. Most of parts were written by Sergey.<br /><br />Best regards,<br />Hayato Kuroda<br />FUJITSU LIMITED<br /> </p></blockquote>