Re: replication_origin and replication_origin_lsn usage on subscriber

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: replication_origin and replication_origin_lsn usage on subscriber
Дата
Msg-id CAA4eK1+9Uzc9+QO7UUrz_89s0NRfS9Yf-+Hfxp_uNTe9tG8WiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: replication_origin and replication_origin_lsn usage on subscriber  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Jul 14, 2020 at 3:37 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
>
> On 14/07/2020 11:36, Dilip Kumar wrote:
> > On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: INSERT INTO SELECT, Why Parallelism is not selected?
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Is it useful to record whether plans are generic or custom?