On Mon, Feb 1, 2021 at 10:14 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Feb 1, 2021 at 9:38 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > On Mon, Feb 1, 2021 at 1:54 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Mon, Feb 1, 2021 at 6:48 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > > > > > On Sun, Jan 31, 2021 at 12:19 AM Amit Kapila <amit.kapil...@gmail.com> > > > > wrote: > > > > > > > > > > I have made the below changes in the patch. Let me know what you think > > > > > about these? > > > > > 1. It was a bit difficult to understand the code in DropSubscription > > > > > so I have rearranged the code to match the way we are doing in HEAD > > > > > where we drop the slots at the end after finishing all the other > > > > > cleanup. > > > > > > > > There was a reason why the v22 logic was different from HEAD. > > > > > > > > The broken connection leaves dangling slots which is unavoidable. > > > > > > > > > > I think this is true only when the user specifically requested it by > > > the use of "ALTER SUBSCRIPTION ... SET (slot_name = NONE)", right? > > > Otherwise, we give an error on a broken connection. Also, if that is > > > true then is there a reason to pass missing_ok as true while dropping > > > tablesync slots? > > > > > > > AFAIK there is always a potential race with DropSubscription dropping > > slots. The DropSubscription might be running at exactly the same time > > the apply worker has just dropped the very same tablesync slot. > > > > We stopped the workers before getting a list of NotReady relations and > then we try to drop the corresponding slots. So, how such a race > condition can happen? >
I think it is possible that the state is still not SYNCDONE but the slot is already dropped so here we should be ready with the missing slot. -- With Regards, Amit Kapila.
