On Thu, Oct 2, 2025 at 12:10 PM Hayato Kuroda (Fujitsu) <[email protected]> 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.
