Re: Impact of checkpointer during pg_upgrade
От | Dilip Kumar |
---|---|
Тема | Re: Impact of checkpointer during pg_upgrade |
Дата | |
Msg-id | CAFiTN-tgW=YwnCTLdreGAgeFTvVn2ByNJcvf-AhEO6kk9=Mv0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Impact of checkpointer during pg_upgrade (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Sep 5, 2023 at 10:55 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > Earlier I was thinking that ERRORing out is better so that the user > > can take necessary action for the invalidated slots and then retry > > upgrade. But thinking again I could not find what are the advantages > > of this because if we error out then also users need to restart the > > old cluster again and have to drop the corresponding subscriptions > > OTOH if we allow the upgrade by ignoring the slots then also the user > > has to take similar actions on the new cluster? So what's the > > advantage of erroring out over upgrading? > > > > The advantage is that we avoid inconvenience caused to users because > Drop Subscription will be unsuccessful as the corresponding slots are > not present. So users first need to disassociate slots for the > subscription and then drop the subscription. Yeah that's a valid argument for erroring out. Also, I am not sure > leaving behind some slots doesn't have any other impact, otherwise, > why don't we drop such slots from time to time after they are marked > invalidated during normal operation? Okay, I am also not sure of that. If users really want to leave > behind such invalidated slots after upgrade, we can even think of > providing some option like "exclude_invalid_logical_slots". +1 -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: