Re: replication_origin and replication_origin_lsn usage on subscriber

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:
>>
>> 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;
>

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. Not sure what Andres'
original intention was with allowing this.

--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/