Hi,
(Sorry but I cannot find your name)
> 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? I want to know other's opinion around here.
Note that if we want to check, it can be done in check_control_data().
Regarding the patch:
```
-
+ cluster->controldata.chkpnt_oldstCommitTsxid = 0;
+ cluster->controldata.chkpnt_newstCommitTsxid = 0;
```
Other attributes are not initialized, you can follow.
```
+ if (old_cluster.controldata.chkpnt_oldstCommitTsxid > 0)
+ copy_subdir_files("pg_commit_ts", "pg_commit_ts");
```
Indent should be fixed. Please run pgindent.
```
- old_cluster.controldata.chkpnt_nxtxid,
- old_cluster.controldata.chkpnt_nxtxid,
+ old_cluster.controldata.chkpnt_oldstCommitTsxid == 0 ? old_cluster.controldata.chkpnt_nxtxid :
old_cluster.controldata.chkpnt_oldstCommitTsxid,
+ old_cluster.controldata.chkpnt_newstCommitTsxid == 0 ? old_cluster.controldata.chkpnt_nxtxid :
old_cluster.controldata.chkpnt_newstCommitTsxid,
```
To confirm, is there a possibility that only either of oldest/newest CommitTs exists?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
