Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Thu, Sep 14, 2023 at 8:40 AM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)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