Dear hackers, > > > > > > I mean instead of resetwal directly modifying the control file we > > > > will modify that value in the server using the binary_upgrade function > > > > and then have that value flush to the disk by shutdown checkpoint. > > > > > > > > > > True, the alternative to consider is to let pg_upgrade update the > > > control file by itself with the required value of OID. The point I am > > > slightly worried about doing via server-side function is that some > > > online and or shutdown checkpoint can update other values in the > > > control file as well whereas if we do via pg_upgrade, we can have > > > better control over just updating the OID. > > > > Yeah, thats a valid point. > > > > But OTOH, just updating the control file via pg_upgrade may not be > sufficient because we should keep the shutdown checkpoint record also > updated with that value. See how pg_resetwal achieves it via > RewriteControlFile() and WriteEmptyXLOG(). So, considering both the > approaches it seems better to go with a server-side function as Robert > suggested.
Based on these discussion, I implemented a server-side approach. An attached patch adds a upgrade function which sets ShmemVariableCache->nextOid. It is called at the end of the upgrade. Comments and name of issue_warnings_and_set_wal_level() is also updated because they become outdated. Best Regards, Hayato Kuroda FUJITSU LIMITED
0001-pg_upgrade-use-upgrade-function-to-restore-OID.patch
Description: 0001-pg_upgrade-use-upgrade-function-to-restore-OID.patch
