Re: Excessive number of replication slots for 12->14 logical replication

On Wed, Aug 24, 2022 at 12:26 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Aug 18, 2022 at 11:28 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > On Thu, Aug 18, 2022 at 3:46 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > Looks good.
> > >
> > > I have one minor comment:
> > >
> > > - * SUBREL_STATE_FINISHEDCOPY. The apply worker can also
> > > - * concurrently try to drop the origin and by this time
> > > - * the origin might be already removed. For these reasons,
> > > - * passing missing_ok = true.
> > > + * SUBREL_STATE_FINISHEDCOPY. So passing missing_ok = true.
> > >
> > > I think we should change "the apply worker" to "the tablesync worker"
> > > but should not remove this sentence. The fact that another process
> > > could concurrently try to drop the origin is still true.
> > >
> > > The rest looks good to me.
> > >
> >
> > Updated as described.
> >
>
> The patch looks good to me though I would like to test it a bit more
> before pushing. Do we want to back-patch this? It is a clear
> improvement as compared to the current implementation but OTOH, users
> can use the workaround of increasing max_replication_slots, so, one
> can say that it is okay to just make this change in HEAD. What do you
> think?
>

I agree. Let's just add the change to HEAD since there is a workaround.

regards,
Ajin Cherian
Fujitsu Australia