Re: replication_origin and replication_origin_lsn usage on subscriber

On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
>
> Hi,
>
> On 14/07/2020 10:29, Amit Kapila wrote:
> > On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >>
> >> On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >>>
> >>> On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >>>>
> >>>> On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >>>>>
> >>>>> On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> If we were to support the origin forwarding, then strictly speaking we
> >>>>>> need everything only at commit time from correctness perspective,
> >>>>>>
> >>>>>
> >>>>> Okay. Anyway streaming mode is optional, so in such cases, we can keep it 'off'
> >>>>>
> >>>>>> but
> >>>>>> ideally origin_id would be best sent with first message as it can be
> >>>>>> used to filter out changes at decoding stage rather than while we
> >>>>>> process the commit so having it set early improves performance of decoding.
> >>>>>>
> >>>>>
> >>>>> Yeah, makes sense. So, we will just send origin_id (with first
> >>>>> streaming start message) and leave others.
> >>>>
> >>>> So IIUC, currently we are sending the latest origin_id which is set
> >>>> during the commit time. So in our case, while we start streaming we
> >>>> will send the origin_id of the latest change in the current stream
> >>>> right?
> >>>>
> >>>
> >>> It has to be sent only once with the first start message not with
> >>> consecutive start messages.
> >>
> >> Okay, so do you mean to say that with the first start message we send
> >> the origin_id of the latest change?
> >>
> >
> > Yes.
> >
> >> because during the transaction
> >> lifetime, the origin id can be changed.
> >>
> >
> > Yeah, it could be changed but if we have to send again apart from with
> > the first message then it should be sent with each message. So, I
> > think it is better to just send it once during the transaction as we
> > do it now (send with begin message).
> >
> >
>
> I am not sure if I can follow the discussion here very well, but if I
> understand correctly I'd like to clarify two things:
> - origin id does not change mid transaction as you can only have one per xid

Actually, I was talking about if someone changes the session origin
then which origin id we should send? currently, we send data only
during the commit so we take the origin id from the commit wal and
send the same. In the below example, I am inserting 2 records in a
transaction and each of them has different origin id.

begin;
select pg_replication_origin_session_setup('o1');
insert into t values(1, 'test');
select pg_replication_origin_session_reset();
select pg_replication_origin_session_setup('o2'); --> Origin ID changed
insert into t values(2, 'test');
commit;

> - until we have origin forwarding feature, the origin id is always same
> for a given subscription

ok

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com