On Thu, Sep 14, 2023 at 8:40 AM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.com> wrote:
> > Here are some more ideas about the issue for reference. > > 1) Extending the controlfile. > > We can dd a new field (e.g. non_upgrade_checkPoint) to record the last check > point > ptr happened in non-upgrade mode. The new field won't be updated due to > "pg_upgrade --check", so pg_upgrade can use this LSN to compare with the > slot's > confirmed_flush_lsn. > > Pros: User can smoothly upgrade the cluster even if they run "pg_upgrade > --check" in advance. > > Cons: Not sure if this is a enough reason to introduce new field in > controlfile. Yeah, this could be an option but I am not sure either that adding a new option for this purpose is the best way. > ----------- > > 2) Advance the slot's confirmed_flush_lsn in pg_upgrade if the check passes. > > Introducing an upgrade support SQL function > (binary_upgrade_advance_logical_slot_lsn()) to set a > flag(catch_confirmed_lsn_up) on server side. On server side, when trying to > flush the slot in shutdown checkpoint(CheckPointReplicationSlots), we update > the slot's confirmed_flush_lsn to the lsn of the current checkpoint if > catch_confirmed_lsn_up is set. > > Pros: User can smoothly upgrade the cluster even if they run "pg_upgrade > --check" in advance. > > Cons: Although we have some examples for using functions > (binary_upgrade_set_next_pg_enum_oid ...) to set some variables during upgrade > , but not sure if it's a standard behavior to change the slot's lsn during > upgrade. I feel this seems like a good option. > ----------- > > 3) Introduce a new pg_upgrade option(e.g. skip_slot_check), and suggest if > user > already did the upgrade check for stopped server, they can use this option > when trying to upgrade later. > > Pros: Can save some efforts for user to advance each slot's lsn. > > Cons: I didn't see similar options in pg_upgrade, might need some agreement. Yeah right, in fact during the --check command we can give that suggestion as well. I feel option 2 looks best to me unless there is some design issue to that, as of now I do not see any issue with that though. Let's see what others think. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
