Re: replication_origin and replication_origin_lsn usage on subscriber

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: replication_origin and replication_origin_lsn usage on subscriber
Дата
Msg-id CAA4eK1JcAiTtHBmvyfzTwy3-u8E2KBQMA-4nga=UAptkeNYSXA@mail.gmail.com
обсуждение исходный текст
Ответ на replication_origin and replication_origin_lsn usage on subscriber  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: replication_origin and replication_origin_lsn usage on subscriber  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> During logical decoding, we send replication_origin and
> replication_origin_lsn when we decode commit.  In pgoutput_begin_txn,
> we send values for these two but never used on the subscriber side.
> Though we have provided a function (logicalrep_read_origin) to read
> these two values but that is not used in code anywhere.
>

For the purpose of decoding in-progress transactions, I think we can
send replication_origin in the first 'start' message as it is present
with each WAL record, however replication_origin_lsn is only logged at
commit time, so can't send it before commit.  The
replication_origin_lsn is set by pg_replication_origin_xact_setup()
but it is not clear how and when that function can be used.  Do we
really need replication_origin_lsn before we decode the commit record?

Note- I have added few more people which I could see are working in a
similar area to get some response.

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



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Performing partition pruning using row value
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Collation versioning