RE: Skipping logical replication transactions on subscriber side

On Monday, October 11, 2021 11:51 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Fri, Oct 8, 2021 at 4:09 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Thursday, September 30, 2021 2:45 PM Masahiko Sawada
> <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > I've attached updated patches that incorporate all comments I got so
> > > far. Please review them.
> > Sorry, if I misunderstand something but did someone check what happens
> > when we execute ALTER SUBSCRIPTION ... RESET (streaming) in the middle
> > of one txn which has several streaming of data to the sub, especially
> > after some part of txn has been already streamed.
> > My intention of this is something like *if* we can find an actual harm
> > of this, I wanted to suggest the necessity of a safeguard or some measure
> into the patch.
...
> > I observed that the subscriber doesn't accept STREAM_COMMIT in this
> > case but gets BEGIN&COMMIT instead at the end.
> > I couldn't find any apparent and immediate issue from those steps but
> > is that no problem ?
> > Probably, this kind of situation applies to other reset target options ?
>
> I think that if a subscription parameter such as ‘streaming’ and ‘binary’ is
> changed, an apply worker exits and the launcher starts a new worker (see
> maybe_reread_subscription()). So I guess that in this case, the apply worker
> exited during receiving streamed changes, restarted, and received the same
> changes with ‘streaming = off’, therefore it got BEGIN and COMMIT instead. I
> think that this happens even by using ‘SET (‘streaming’ = off)’.
You are right. Yes, I checked that the apply worker did exit
and the new apply worker process dealt with the INSERT in the above case.
Also, setting streaming = false was same.

Thanks a lot for your explanation.

Best Regards,
Takamichi Osumi