In pg_upgrade, we reset WAL archives (remove WAL), transaction id, etc. in copy_xact_xlog_xid() for the new cluster. Then, we create new objects in the new cluster, and again towards the end of the upgrade we invoke pg_resetwal with the -o option to reset the next OID. Now, along with resetting the OID, pg_resetwal will again reset the WAL. I am not sure if that is intentional and it may not have any problem today except that it seems redundant to reset WAL again.
However, this can be problematic for the ongoing work to upgrade the logical replication slots [1]. We want to create/migrate logical slots in the new cluster before calling the final pg_resetwal (which resets the next OID) to ensure that there is no new WAL inserted by background processes or otherwise between resetwal location and creation of slots. So, we thought that we would compute the next WAL location by doing the computation similar to what pg_resetwal does to reset a new WAL location, create slots using that location, and pass the same to pg_resetwal using the -l option. However, that doesn't work because pg_resetwal uses the passed -l option only as a hint but can reset the later WAL if present which can remove the WAL position we have decided as restart_lsn (point to start reading WAL) for slots. So, we came up with another idea that we will reset the WAL just before creating slots and use that location to create slots and then invent a new option in pg_resetwal where it won't reset the WAL. Now, as mentioned in the first paragraph, it seems we anyway don't need to reset the WAL at the end when setting the next OID for the new cluster with the -o option. If that is true, then I think even without slots work it will be helpful to have such an option in pg_resetwal. Thoughts? [1] - https://commitfest.postgresql.org/45/4273/ -- With Regards, Amit Kapila.
