Re: Patch for migration of the pg_commit_ts directory

On Thu, Oct 2, 2025 at 12:10 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> > Yes, track_commit_timestamp must be installed in the new instance.
> > This is only the responsibility of an experienced user.
> > pg_upgrage should allow you to save pg_commit_ts if this data exists at the time of migration.
> > Warnings are not needed, the loss of this data is not critical in most cases.
> > They were lost with each migration if users did not manually migrate them.
>
> So, your policy is that commit_ts is not the user data thus it is OK to drop during
> the upgrade, is it correct?
>

IIUC, the proposal is that if GUC track_commit_timestamp is enabled on
the new instance then we should copy it, otherwise, we can drop
copying it. Is my understanding correct? I think we can follow what is
done check_new_cluster_replication_slots() for the case when
track_commit_timestamp is not set on the new server. 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?

--
With Regards,
Amit Kapila.