Re: replication_origin and replication_origin_lsn usage on subscriber - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: replication_origin and replication_origin_lsn usage on subscriber
Date
Msg-id CAA4eK1JcAiTtHBmvyfzTwy3-u8E2KBQMA-4nga=UAptkeNYSXA@mail.gmail.com
Whole thread Raw
In response to replication_origin and replication_origin_lsn usage on subscriber  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: replication_origin and replication_origin_lsn usage on subscriber
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Performing partition pruning using row value
Next
From: Julien Rouhaud
Date:
Subject: Re: Collation versioning