Re: Impact of checkpointer during pg_upgrade

On Fri, Sep 8, 2023 at 11:59 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Sep 8, 2023 at 10:10 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> > On Fri, Sep 08, 2023 at 09:14:59AM +0530, Amit Kapila wrote:
> > > On Fri, Sep 8, 2023 at 9:00 AM Zhijie Hou (Fujitsu)
> > > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > >>> I
> > >>> mean that doing the latter is benefitial for the sake of any patch committed and
> > >>> as a long-term method to rely on.
> > >
> > > What is your worry here? Are you worried that unknowingly in the
> > > future we could add some other way to invalidate slots during upgrades
> > > that we won't be able to detect?
> >
> > Exactly. A safety belt would not hurt, especially if the belt added
> > is simple. The idea of a backend side elog(ERROR) with
> > isBinaryUpgrade is tempting in the invalidation slot path.
> >
>
> I agree with doing something simple. So, to conclude, we agree on two
> things in this thread (a) Use max_slot_wal_keep_size to -1 to start
> postmaster for the old cluster during the upgrade; (b) Have an
> elog(ERROR) to avoid invalidating slots during the upgrade.

+1

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com