Re: Patch for migration of the pg_commit_ts directory

On Thu, 15 Oct 2026 at 06:54, Hayato Kuroda (Fujitsu) <
kuroda(dot)hayato(at)fujitsu(dot)com> wrote:

> Hi hackers,
>
> I did a self reviewing for 0001 and 0002, and updated the doc a bit.
> PSA new patch set.
>
> > If you accept part 1, many users who use logical replication will see
> > many messages like “conflict detected on relation” that didn’t exist
> before.
>
> Sorry, I'm not sure the part, can you please clarify more? When can it
> happen?
>
> Sorry for my brief absence; I’ve been a bit busy lately. Anyway,
I think Sergey is trying to say that without the second patch, users
might encounter false-positive errors.

You see, we do change pg_resetwal here:
exec_prog(UTILITY_LOG_FILE, NULL, true, true,
"\"%s/pg_resetwal\" -f -c %u,%u \"%s\"",
new_cluster.bindir,
- old_cluster.controldata.chkpnt_nxtxid,
- old_cluster.controldata.chkpnt_nxtxid,
+ oldest_xid,
+ newest_xid,
new_cluster.pgdata);

Thus, we change the tuples XID valid range of some sort.

Prior to this patch, a call of TransactionIdGetCommitTsData() would
return false, meaning no origin_differs were calculated and,
consequently, no messages were generated.

With 0001, we are effectively modifying the permissible XID range for
tuples. XIDs limits are restored from old cluster. Then lookup will
succeed and conflict detection will be reported. This is likely false
positive, but very annoying.

And patch 0001 makes this behavior the only option.
0002 makes it opt-in.

In short, if I were the committer, I wouldn’t consider committing patch
0001 separately from 0002.

--
Best regards,
Maxim Orlov.