Re: Impact of checkpointer during pg_upgrade
От | Dilip Kumar |
---|---|
Тема | Re: Impact of checkpointer during pg_upgrade |
Дата | |
Msg-id | CAFiTN-vp8f_wg4c6qnWqat_YBAOmrNrZANCEn51tCu76kxK1cw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Impact of checkpointer during pg_upgrade (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Fri, Sep 8, 2023 at 11:59 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Sep 8, 2023 at 10:10 AM Michael Paquier <michael@paquier.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.fnst@fujitsu.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
В списке pgsql-hackers по дате отправления: