Re: Impact of checkpointer during pg_upgrade - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Impact of checkpointer during pg_upgrade
Date
Msg-id CAFiTN-tgW=YwnCTLdreGAgeFTvVn2ByNJcvf-AhEO6kk9=Mv0A@mail.gmail.com
Whole thread Raw
In response to Re: Impact of checkpointer during pg_upgrade  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_upgrade fails with in-place tablespace[
Next
From: vignesh C
Date:
Subject: Re: persist logical slots to disk during shutdown checkpoint