On Thu, Aug 10, 2023 at 10:37:04PM +0900, Masahiko Sawada wrote: > On Thu, Aug 10, 2023 at 12:52 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Are you suggesting doing this before we start the old cluster or after > > we stop the old cluster? I was thinking about the pros and cons of > > doing this check when the server is 'on' (along with other upgrade > > checks something like the patch is doing now) versus when the server > > is 'off'. I think the advantage of doing it when the server is 'off' > > (after check_and_dump_old_cluster()) is that it will be ensured that > > there is no extra WAL that could be generated during the upgrade and > > has not been verified against confirmed_flush_lsn location. But OTOH, > > to retrieve slot information when the server is 'off', we need a > > separate utility or probably a functionality for the same in > > pg_upgrade and also some WAL reading stuff which sounds to me like a > > larger change that may not be warranted here. I think anyway the extra > > WAL (if any got generated during the upgrade) won't be required after > > the upgrade so not convinced to make such a check while the server is > > 'off'. Are there reasons which make it better to do this while the old > > cluster is 'off'? > > What I imagined is that we do this check before > check_and_dump_old_cluster() while the server is 'off'. Reading the > slot state file would be simple and I guess we would not need a tool > or cli program for that.
Agreed. > BTW this check would not be able to support live-check but I think > it's not a problem as this check with a running server will never be > able to pass. Agreed. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
