Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1LiD-6nfLzaB77PVCjRLvkdH_FUBBVj7qSEGhn3VCHsfQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Skipping logical replication transactions on subscriber side ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>) |
Список | pgsql-hackers |
On Mon, Oct 11, 2021 at 12:57 PM osumi.takamichi@fujitsu.com <osumi.takamichi@fujitsu.com> wrote: > > On Monday, October 11, 2021 11:51 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Oct 8, 2021 at 4:09 PM osumi.takamichi@fujitsu.com > > <osumi.takamichi@fujitsu.com> wrote: > > > > > > On Thursday, September 30, 2021 2:45 PM Masahiko Sawada > > <sawada.mshk@gmail.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. > I think you can additionally verify that temporary streaming files get removed after restart. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: