On Sat, Oct 7, 2023 at 3:46 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Oct 6, 2023 at 6:30 PM Hayato Kuroda (Fujitsu) > > > > Based on that, I added another binary function > > binary_upgrade_create_logical_replication_slot(). > > This function is similar to pg_create_logical_replication_slot(), but the > > restart_lsn and confirmed_flush are set to *next* WAL segment. The pointed > > filename is returned and it is passed to pg_resetwal command. > > > > I am not sure if it is a good idea that a > binary_upgrade_create_logical_replication_slot() API does the logfile > name calculation. >
The other problem is that pg_resetwal removes all pre-existing WAL files which in this case could lead to the removal of the WAL file corresponding to restart_lsn. This is because at least the shutdown checkpoint record will be written after the creation of slots which could be in the new file used for restart_lsn. Then when we invoke pg_resetwal, it can remove that file. One idea to deal with this could be to do the reset WAL stuff (FindEndOfXLOG(), KillExistingXLOG(), KillExistingArchiveStatus(), WriteEmptyXLOG()) in a separate function (say in pg_upgrade) and then create slots. If we do this, then we additionally need an option in pg_resetwal which skips resetting the WAL as that would have been done before creating the slots. -- With Regards, Amit Kapila.
