Re: replication_origin and replication_origin_lsn usage on subscriber

On Tue, Jul 14, 2020 at 3:37 PM Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
>
> On 14/07/2020 11:36, Dilip Kumar wrote:
> > On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
> >>
> >> 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;
> >
>
> Commit record and commit_ts record will both include only 'o2', while
> individual DML WAL records will contain one or the other depending on
> when they were done.
>
> The origin API is really not really prepared for this situation
> (independently of streaming) because the origin lookup for all rows in
> that transaction will return 'o2', but decoding will decode whatever is
> in the DML WAL record.
>
> One can't even use this approach for sensible filtering as the ultimate
> faith of whole transaction is decided by what's in commit record since
> the filter callback only provides origin id, not record being processed
> so plugin can't differentiate. So it's hard to see how the above pattern
> could be used for anything but breaking things.
>

Fair enough, I think we can proceed with the assumption that it won't
change during the transaction and send origin_id along with the very
first *start* message during the streaming of in-progress
transactions.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com