From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Greg Nancarrow <gregn4422(at)gmail(dot)com> |
Subject: | Re: Skipping logical replication transactions on subscriber side |
Date: | 2021-10-18 08:48:46 |
Message-ID: | CAA4eK1LiD-6nfLzaB77PVCjRLvkdH_FUBBVj7qSEGhn3VCHsfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 11, 2021 at 12:57 PM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
>
> 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.
>
I think you can additionally verify that temporary streaming files get
removed after restart.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-10-18 09:02:35 | Re: Data is copied twice when specifying both child and parent table in publication |
Previous Message | houzj.fnst@fujitsu.com | 2021-10-18 08:46:13 | RE: Data is copied twice when specifying both child and parent table in publication |