Re: Patch for migration of the pg_commit_ts directory

Hi,

Thank you for the great work. This way, you can indeed apply patches in
parts.

I think that if patch [1] is in development, you can apply parts 1 and 2.

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.

If you apply part 2, there will be no such messages, even though
track_commit_timestamp = on.

For them to appear, you need to read the documentation and understand
why you need to specify --pg-commit-ts and what the consequences will be.

The chances of accepting part 3 are very low, especially if patch [1] is
available.

Accepting parts 1 and 2 increases the chances of accepting patch [1].

After patch [1] is applied, all side effects of the pg_commit_ts
migration will disappear. The presence of the --pg-commit-ts key
provides more options. Perhaps someone will use migration to change
server settings. And setting track_commit_timestamp = off in a new
cluster is also an option.

[1]: https://www.postgresql.org/message-id/CAFPTHDbPXU7cs189J=BrzSa20EJzajOU25N7G7nT6UZqMkRnXg@mail.gmail.com

25.08.2026 13:46, Hayato Kuroda (Fujitsu) пишет:
> Dear Sergey,
>
>> I was writing emails in the browser. I am writing this letter and
>> sending it in the mail client. The letter format is plain text. I think
>> this should fix the problem.
> Yes, solved. Thanks for the corporation.
>
>> You do not need to check for files in the pg_commit_ts directory in the
>> new cluster BEFORE the copy operation. These files are not needed. This
>> patch is designed to copy the pg_commit_ts directory from the old
>> cluster. If the user does not want to copy the pg_commit_ts directory,
>> it is enough not to specify the --pg-commit-ts option. This is the
>> default behavior. And for most, this is a suitable option.
> OK, understood. Let me think over it again...
>
> BTW, I still think this patch must be coordinate with the migration of replication
> origins [1], and this patch itself should not handle the origin migration.
> To separate them clearly, I split your patch into three parts:
>
> 0001 - migrate commit_ts sub directory.
> 0002 - add --pg-commit-ts option. (Actually I'm not sure it's needed)
> 0003 - Save and restore the roident and remote_lsn from the old cluster.
> IIUC it's not needed if [1] is pushed.
>
> I feel this method allows patches to be pushed separately. How do you feel?
>
> [1]: https://www.postgresql.org/message-id/CAFPTHDbPXU7cs189J=BrzSa20EJzajOU25N7G7nT6UZqMkRnXg@mail.gmail.com
>
> Best regards,
> Hayato Kuroda
> FUJITSU LIMITED
>