On Thu, Sep 28, 2023 at 2:22 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Fri, Sep 22, 2023 at 9:40 AM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Thu, Sep 21, 2023 at 01:50:28PM +0530, Amit Kapila wrote:
> > > We have discussed this point. Normally, we don't have such options in
> > > upgrade, so we were hesitent to add a new one for this but there is a
> > > discussion to add an --exclude-logical-slots option. We are planning
> > > to add that as a separate patch after getting some more consensus on
> > > it. Right now, the idea is to get the main patch ready.
> >
> > Okay. I am wondering if the subscriber part is OK now without an
> > option, but that could also be considered separately, as well. At
> > least I hope so.
>
> +1 for an option to skip upgrade logical replication slots for the
> following reasons:
> - one may not want the logical replication slots on the upgraded
> instance immediately - unless the upgraded instance is tested and
> determined to be performant.
> - one may not want the logical replication slots on the upgraded
> instance immediately - no logical replication setup is wanted on the
> new instance perhaps because of an architectural/organizational
> decision.
> - one may take backup of the postgres instance with logical
> replication slots using any of the file system/snapshot based backup
> mechanisms (not pg_basebackup), essentially getting the on-disk
> replication slots data as well; the pg_upgrade may fail on the
> backed-up instance.
>
> I agree to have it as a 0002 patch once the design and things are
> finalized for the main patch.
>
Thanks for understanding that it can be done as a 0002 patch because
we don't have an agreement on this. Jonathan feels exactly the
opposite for having an option that by default doesn't migrate slots as
users always need to use the option and they may want to have slots
migrated by default. So, we may consider to have an --exclude-*
option.
--
With Regards,
Amit Kapila.