Hi,

On Wed, Mar 11, 2026 at 10:51 AM ls7777 <ls7777@yandex.ru> wrote:

 Hello,
 I saw a big comment that I had missed.
 Added fixes in two patches:
 v11-0001-Migration-of-the-pg_commit_ts-directory.patch - main changes
 v11-0002-Migration-of-the-pg_commit_ts-directory-desc.patch - changes to documentation and comments


 ----------------
 Кому: 'ls7777' (ls7777@yandex.ru);
 Копия: pgsql-hackers@postgresql.org, orlovmg@gmail.com;
 Тема: Patch for migration of the pg_commit_ts directory;
 11.03.2026, 12:55, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>:

 Dear Sergey,


  I don't understand what I need to do.
 Subject: [PATCH v10] Migration of the pg_commit_ts directory
  I have specified a new version in the patch. Do I need to add anything else?


 When we see the commit message in postgres repo, you can see that each commit
 contain the background, what we did in the commit, considerations, and etc.
 Compared with them, the description you added seems insufficient.
 Of course the committer will take care, but Amit suggested [1] to write a draft.
 The basic style guide is determined in [2].

 Actually I wrote a draft for the patch set in v9-0002, but you miss. You may
 able to refer it, and re-create new version or use the same one.
 

I've reviewed this patch and have one question.

The commit timestamp has not only the timestamp data but also
replication origin id. The replication origin id assigned to the
subscription on the new cluster is not necessarily the same as the
ones assigned on the old cluster. Therefore, if there is mismatch,
replication conflict 'update_origin_differs' could wrongly happen,
even though the new subscriber starts logical replication from the
same publisher. I've confirmed this behavior in the following
scenario:

1. Setup publication.
-- on publisher
CREATE TABLE test (id int primary key, t text);
CREATE PUBLICATION pub FOR TABLE test;

2. Setup subscription.
-- on subscriber
CREATE TABLE test (id int primary key, t text);
CREATE SUBSCRIPTION mysub CONNECTION '...' PUBLICATION pub;
CREATE SUBSCRIPTION a_dummy CONNECTION '...' PUBLICATION pub WITH
(connect = false, enabled = false);

-- confirm that mysub's origin id is 1 and a_dummy's origin id is 2.
SELECT oid, subname FROM pg_subscription;
  oid | subname
-------+---------
 16392 | mysub
 16393 | a_dummy
(2 rows)

SELECT * FROM pg_replication_origin;
 roident | roname
---------+----------
       1 | pg_16392
       2 | pg_16393
(2 rows)

3. Insert a tuple to the test table and wait for it to be replicated.
-- on publisher
INSERT INTO test VALUES (1, 'replicated change');

The change is applied on the subscription with replication origin id 1:
-- on subscriber
SELECT * FROM test, pg_xact_commit_timestamp_origin(test.xmin);
 id | c | timestamp | roident
----+-------------------+-------------------------------+---------
  1 | replicated change | 2026-03-16 13:49:35.211316-07 | 1
(1 row)

4. Do pg_upgrade
5. Check the replication origins in the new subscriber

SELECT oid, subname FROM pg_subscription;
 oid | subname
-------+---------
 16402 | a_dummy
 16403 | mysub
(2 rows)

SELECT * FROM pg_replication_origin;
 roident | roname
---------+----------
       1 | pg_16402
       2 | pg_16403
(2 rows)

The replication origin 1 is now used by a_dummy subscription.

6. Update the tuple on the publisher
-- on publisher
UPDATE test SET c = 'change after upgrade' WHERE id = 1;

Then I got the following LOG:

LOG: conflict detected on relation "public.test":
conflict=update_origin_differs
2026-03-16 13:53:41.992 PDT [1247879] DETAIL: Updating the row that
was modified by a different origin "pg_16402" in transaction 760 at
2026-03-16 13:53:33.448002-07: local row (1, replicated change),
remote row (1, change after upgrade), replica identity (id)=(1).
2026-03-16 13:53:41.992 PDT [1247879] CONTEXT: processing remote data
for replication origin "pg_16403" during message type "UPDATE" for
replication target relation "public.test" in transaction 664, finished
at 0/017ED910

I think that this patch works fine only when users don't use the
replication origins. On the other hand, I think we should ensure that
subscriptions use the same replication origins even after upgrade in
cases where users are upgrading subscribers.

Also, regarding the patch, with the following change we disallow the
case where users want to disable the commit timestamp in the new
cluster. IIUC migrating the commit timestamps is not mandatory in
practice, so I think we do the migration when applicable or raise a
warning if only the new cluster disables the commit timestamps.

+ if (!commit_ts_is_enabled &&
+ old_cluster.controldata.chkpnt_newstCommitTsxid > 0)
+ pg_fatal("\"track_commit_timestamp\" must be \"on\" but is set
to \"off\"");
+

Regards,
 

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com