Hi,

I'll try to return it to the original thread.

I absolutely agree with you. Data loss during migration is an unacceptable situation. And why it's still happening, I don't understand. But issuing messages will require translating it into other languages and complicate the patch. I'm not a programmer to do it beautifully. And not a beautiful patch is unlikely to be accepted.

I will do a parameter check and an ERROR message.

Hi,

Could you please reply to the original thread? Otherwise, it is difficult to track later.
Regarding the patch, I think Amit suggested to raise an ERROR in case of parameter
mismatch, and Maxim agreed the point [2]. How do you feel?

[1]: https://www.postgresql.org/message-id/CAA4eK1%2BZayox%3Dx84upet_gc4hrCKSwZSpnO9%3DQ4vH8rrJbsBOg%40mail.gmail.com
[2]: https://www.postgresql.org/message-id/CACG%3DezaFdL4EM8bdrHTRVHt5BmxxWGXcPiDr6Qm00Qj%2BS_Y%2BvQ%40mail.gmail.com

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Кому: Amit Kapila (amit.kapila16@gmail.com);

Копия: Hayato Kuroda (Fujitsu) (kuroda.hayato@fujitsu.com), pgsql-hackers@postgresql.org;

Тема: Patch for migration of the pg_commit_ts directory;

06.10.2025, 12:59, "Maxim Orlov" <orlovmg@gmail.com>:

On Thu, 2 Oct 2025 at 11:49, Amit Kapila <amit.kapila16@gmail.com> wrote:

When we try to
copy slots and the wal_level on the new server is minimal, we error
out, so shouldn't we do the same here and error_out if
track_commit_timestamp is not enabled and we have some valid commit_ts
data to copy?

+1 Sounds reasonable to me. It's better to give an explicit error;
otherwise, we would remove data that the user clearly wants to migrate
to the new cluster. And deleting data just because the user forgot to
specify one parameter in a new cluster looks like a bad joke to me.

Best regards,

Maxim Orlov.