On 09/07/2020 13:10, Amit Kapila wrote:
> 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.
>>
We don't use the origin message anywhere really because we don't support
origin forwarding in the built-in replication yet. That part I left out
intentionally in the original PG10 patchset as it's mostly useful for
circular replication detection when you want to replicate both ways.
However that's relatively useless without also having some kind of
conflict detection which would be another huge pile of code and I
expected we would end up not getting logical replication in PG10 at all
if I tried to push conflict detection as well :)
>
> 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?
>
That's the SQL interface, C interface does not require that and I don't
think we need to do that. The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
