<div>+ amit.kapila16@</div><div> </div><div>Hi,</div><div> </div><div><div>I will check for subscriptions and if there are any, there will be no migration of the pg_commit_timestamp directory (the behavior will be standard).</div><div> </div><div><blockquote><div>I think that this patch works fine only when users don't use the<br />replication origins. On the other hand, I think we should ensure that<br />subscriptions use the same replication origins even after upgrade in<br />cases where users are upgrading subscribers.</div></blockquote></div><div><div>I do not know how to do this.</div></div><div> </div><div><blockquote><div>Also, regarding the patch, with the following change we disallow the<br />case where users want to disable the commit timestamp in the new<br />cluster. IIUC migrating the commit timestamps is not mandatory in<br />practice, so I think we do the migration when applicable or raise a<br />warning if only the new cluster disables the commit timestamps.</div></blockquote></div><div> </div><div><div>This is a safer strategy to help you avoid losing the data that the user needs. I received a recommendation to do so.</div></div><div><div>Should I issue a warning about loss of transaction commit times?</div><div>Write the text I need to output.</div></div><div> </div></div><div>----------------</div><div>Кому: ls7777 (ls7777(at)yandex(dot)ru);</div><div>Копия: Hayato Kuroda (Fujitsu) (kuroda(dot)hayato(at)fujitsu(dot)com), pgsql-hackers(at)postgresql(dot)org, orlovmg(at)gmail(dot)com;</div><div>Тема: Patch for migration of the pg_commit_ts directory;</div><div>17.03.2026, 02:04, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>:</div><blockquote><p>Hi,<br /><br />On Wed, Mar 11, 2026 at 10:51 AM ls7777 <<a href="mailto:ls7777(at)yandex(dot)ru" rel="noopener noreferrer">ls7777(at)yandex(dot)ru</a>> wrote:</p><blockquote><br /> Hello,<br /> I saw a big comment that I had missed.<br /> Added fixes in two patches:<br /> v11-0001-Migration-of-the-pg_commit_ts-directory.patch - main changes<br /> v11-0002-Migration-of-the-pg_commit_ts-directory-desc.patch - changes to documentation and comments<br /><br /><br /> ----------------<br /> Кому: 'ls7777' (<a href="mailto:ls7777(at)yandex(dot)ru" rel="noopener noreferrer">ls7777(at)yandex(dot)ru</a>);<br /> Копия: <a href="mailto:pgsql-hackers(at)postgresql(dot)org" rel="noopener noreferrer">pgsql-hackers(at)postgresql(dot)org</a>, <a href="mailto:orlovmg(at)gmail(dot)com" rel="noopener noreferrer">orlovmg(at)gmail(dot)com</a>;<br /> Тема: Patch for migration of the pg_commit_ts directory;<br /> 11.03.2026, 12:55, "Hayato Kuroda (Fujitsu)" <<a href="mailto:kuroda(dot)hayato(at)fujitsu(dot)com" rel="noopener noreferrer">kuroda(dot)hayato(at)fujitsu(dot)com</a>>:<br /><br /> Dear Sergey,<br /><br /><br /> I don't understand what I need to do.<br /> Subject: [PATCH v10] Migration of the pg_commit_ts directory<br /> I have specified a new version in the patch. Do I need to add anything else?<br /><br /><br /> When we see the commit message in postgres repo, you can see that each commit<br /> contain the background, what we did in the commit, considerations, and etc.<br /> Compared with them, the description you added seems insufficient.<br /> Of course the committer will take care, but Amit suggested [1] to write a draft.<br /> The basic style guide is determined in [2].<br /><br /> Actually I wrote a draft for the patch set in v9-0002, but you miss. You may<br /> able to refer it, and re-create new version or use the same one.<br /> </blockquote><p><br />I've reviewed this patch and have one question.<br /><br />The commit timestamp has not only the timestamp data but also<br />replication origin id. The replication origin id assigned to the<br />subscription on the new cluster is not necessarily the same as the<br />ones assigned on the old cluster. Therefore, if there is mismatch,<br />replication conflict 'update_origin_differs' could wrongly happen,<br />even though the new subscriber starts logical replication from the<br />same publisher. I've confirmed this behavior in the following<br />scenario:<br /><br />1. Setup publication.<br />-- on publisher<br />CREATE TABLE test (id int primary key, t text);<br />CREATE PUBLICATION pub FOR TABLE test;<br /><br />2. Setup subscription.<br />-- on subscriber<br />CREATE TABLE test (id int primary key, t text);<br />CREATE SUBSCRIPTION mysub CONNECTION '...' PUBLICATION pub;<br />CREATE SUBSCRIPTION a_dummy CONNECTION '...' PUBLICATION pub WITH<br />(connect = false, enabled = false);<br /><br />-- confirm that mysub's origin id is 1 and a_dummy's origin id is 2.<br />SELECT oid, subname FROM pg_subscription;<br /> oid | subname<br />-------+---------<br /> 16392 | mysub<br /> 16393 | a_dummy<br />(2 rows)<br /><br />SELECT * FROM pg_replication_origin;<br /> roident | roname<br />---------+----------<br /> 1 | pg_16392<br /> 2 | pg_16393<br />(2 rows)<br /><br />3. Insert a tuple to the test table and wait for it to be replicated.<br />-- on publisher<br />INSERT INTO test VALUES (1, 'replicated change');<br /><br />The change is applied on the subscription with replication origin id 1:<br />-- on subscriber<br />SELECT * FROM test, pg_xact_commit_timestamp_origin(test.xmin);<br /> id | c | timestamp | roident<br />----+-------------------+-------------------------------+---------<br /> 1 | replicated change | 2026-03-16 13:49:35.211316-07 | 1<br />(1 row)<br /><br />4. Do pg_upgrade<br />5. Check the replication origins in the new subscriber<br /><br />SELECT oid, subname FROM pg_subscription;<br /> oid | subname<br />-------+---------<br /> 16402 | a_dummy<br /> 16403 | mysub<br />(2 rows)<br /><br />SELECT * FROM pg_replication_origin;<br /> roident | roname<br />---------+----------<br /> 1 | pg_16402<br /> 2 | pg_16403<br />(2 rows)<br /><br />The replication origin 1 is now used by a_dummy subscription.<br /><br />6. Update the tuple on the publisher<br />-- on publisher<br />UPDATE test SET c = 'change after upgrade' WHERE id = 1;<br /><br />Then I got the following LOG:<br /><br />LOG: conflict detected on relation "public.test":<br />conflict=update_origin_differs<br />2026-03-16 13:53:41.992 PDT [1247879] DETAIL: Updating the row that<br />was modified by a different origin "pg_16402" in transaction 760 at<br />2026-03-16 13:53:33.448002-07: local row (1, replicated change),<br />remote row (1, change after upgrade), replica identity (id)=(1).<br />2026-03-16 13:53:41.992 PDT [1247879] CONTEXT: processing remote data<br />for replication origin "pg_16403" during message type "UPDATE" for<br />replication target relation "public.test" in transaction 664, finished<br />at 0/017ED910<br /><br />I think that this patch works fine only when users don't use the<br />replication origins. On the other hand, I think we should ensure that<br />subscriptions use the same replication origins even after upgrade in<br />cases where users are upgrading subscribers.<br /><br />Also, regarding the patch, with the following change we disallow the<br />case where users want to disable the commit timestamp in the new<br />cluster. IIUC migrating the commit timestamps is not mandatory in<br />practice, so I think we do the migration when applicable or raise a<br />warning if only the new cluster disables the commit timestamps.<br /><br />+ if (!commit_ts_is_enabled &&<br />+ old_cluster.controldata.chkpnt_newstCommitTsxid > 0)<br />+ pg_fatal("\"track_commit_timestamp\" must be \"on\" but is set<br />to \"off\"");<br />+<br /><br />Regards,<br /> </p>--<br />Masahiko Sawada<br />Amazon Web Services: <a href="https://aws.amazon.com/" rel="noopener noreferrer">https://aws.amazon.com</a></blockquote>