Re: Patch for migration of the pg_commit_ts directory
ls7777 <ls7777@yandex.ru>
From: ls7777 <ls7777@yandex.ru>
To: "orlovmg@gmail.com" <orlovmg@gmail.com>, "amit.kapila16@gmail.com" <amit.kapila16@gmail.com>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2025-10-06T17:30:29Z
Lists: pgsql-hackers
Attachments
- (unnamed) (text/html)
- v3-Migration-of-the-pg_commit_ts-directory.patch (text/x-diff)
Hi.
Added a fatal message about an incorrect track_commit_timestamp parameter for new cluster. Update test.
Fail check:
Checking for new cluster tablespace directories ok
Checking for pg_commit_ts
"track_commit_timestamp" must be "on" but is set to "off"
Successful:
Checking for new cluster tablespace directories ok
Checking for pg_commit_ts ok
...
----------------
Кому: 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.