replication_origin and replication_origin_lsn usage on subscriber
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.
I think this is primarily for external application usage, but it is
not very clear how will they use it. As far as I understand, the
value of origin can be used to avoid loops in bi-directional
replication, and origin_lsn can be used to track how far subscriber
has recevied changes. I am not sure about this and particularly how
origin_lsn can be used in external applications.
This has come up in the discussion of the "logical streaming of large
in-progress transactions" [1]/messages/by-id/CAFiTN-skHvSWDHV66qpzMfnHH6AvsE2YAjvh4Kt613E8ZD8WoQ@mail.gmail.com. Basically, we are not sure when to send
these values during streaming as we don't know its clear usage.
Thoughts?
[1]: /messages/by-id/CAFiTN-skHvSWDHV66qpzMfnHH6AvsE2YAjvh4Kt613E8ZD8WoQ@mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
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
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/
On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
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 :)
Fair enough. However, without tests and more documentation about this
concept, it is likely that future development might break it. It is
good that you and others who know this part well are there to respond
but still, the more documentation and tests would be preferred.
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.
I think when you are saying SQL interface, you referred to
pg_replication_origin_xact_setup() but I am not sure which C interface
you are referring to in the above sentence?
The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.
That's correct. However, we do send it via 'begin' callback which
won't be possible with the streaming of in-progress transactions. Do
we need to send this origin related information (origin, origin_lsn)
while streaming of in-progress transactions? If so, when? As far as
I can see, the origin_id can be sent with the first 'start' message.
The origin_lsn and origin_commit can be sent with the last 'start' of
streaming commit if we want but not sure if that is of use. If we
need to send origin_lsn earlier than that then we need to record it
with other WAL records (other than Commit WAL record).
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Hi,
On 09/07/2020 14:34, Amit Kapila wrote:
On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
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 :)Fair enough. However, without tests and more documentation about this
concept, it is likely that future development might break it. It is
good that you and others who know this part well are there to respond
but still, the more documentation and tests would be preferred.
Honestly that part didn't even need to be committed given it's unused.
Protocol supports versioning so it could have been added at later time.
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.I think when you are saying SQL interface, you referred to
pg_replication_origin_xact_setup() but I am not sure which C interface
you are referring to in the above sentence?
All the stuff pg_replication_origin_xact_setup does internally.
The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.That's correct. However, we do send it via 'begin' callback which
won't be possible with the streaming of in-progress transactions. Do
we need to send this origin related information (origin, origin_lsn)
while streaming of in-progress transactions? If so, when? As far as
I can see, the origin_id can be sent with the first 'start' message.
The origin_lsn and origin_commit can be sent with the last 'start' of
streaming commit if we want but not sure if that is of use. If we
need to send origin_lsn earlier than that then we need to record it
with other WAL records (other than Commit WAL record).
If we were to support the origin forwarding, then strictly speaking we
need everything only at commit time from correctness perspective, 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.
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
Hi,
On 09/07/2020 14:34, Amit Kapila wrote:
On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
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 :)Fair enough. However, without tests and more documentation about this
concept, it is likely that future development might break it. It is
good that you and others who know this part well are there to respond
but still, the more documentation and tests would be preferred.Honestly that part didn't even need to be committed given it's unused.
Protocol supports versioning so it could have been added at later time.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.I think when you are saying SQL interface, you referred to
pg_replication_origin_xact_setup() but I am not sure which C interface
you are referring to in the above sentence?All the stuff pg_replication_origin_xact_setup does internally.
The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.That's correct. However, we do send it via 'begin' callback which
won't be possible with the streaming of in-progress transactions. Do
we need to send this origin related information (origin, origin_lsn)
while streaming of in-progress transactions? If so, when? As far as
I can see, the origin_id can be sent with the first 'start' message.
The origin_lsn and origin_commit can be sent with the last 'start' of
streaming commit if we want but not sure if that is of use. If we
need to send origin_lsn earlier than that then we need to record it
with other WAL records (other than Commit WAL record).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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
Hi,
On 09/07/2020 14:34, Amit Kapila wrote:
On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
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 :)Fair enough. However, without tests and more documentation about this
concept, it is likely that future development might break it. It is
good that you and others who know this part well are there to respond
but still, the more documentation and tests would be preferred.Honestly that part didn't even need to be committed given it's unused.
Protocol supports versioning so it could have been added at later time.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.I think when you are saying SQL interface, you referred to
pg_replication_origin_xact_setup() but I am not sure which C interface
you are referring to in the above sentence?All the stuff pg_replication_origin_xact_setup does internally.
The existing apply code sets the
replorigin_session_origin_lsn only when processing commit message IIRC.That's correct. However, we do send it via 'begin' callback which
won't be possible with the streaming of in-progress transactions. Do
we need to send this origin related information (origin, origin_lsn)
while streaming of in-progress transactions? If so, when? As far as
I can see, the origin_id can be sent with the first 'start' message.
The origin_lsn and origin_commit can be sent with the last 'start' of
streaming commit if we want but not sure if that is of use. If we
need to send origin_lsn earlier than that then we need to record it
with other WAL records (other than Commit WAL record).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? I think we will always have to remember the latest origin id
in top-level ReorderBufferTXN as well.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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? because during the transaction
lifetime, the origin id can be changed. Currently, we send the
origin_id of the latest WAL i.e. origin id of the commit. so I think
it will be on a similar line if with every stream_start we send the
origin_id of the latest change in that stream.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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).
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Hi,
On 14/07/2020 10:29, Amit Kapila wrote:
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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
- until we have origin forwarding feature, the origin id is always same
for a given subscription
--
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
Hi,
On 14/07/2020 10:29, Amit Kapila wrote:
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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;
- until we have origin forwarding feature, the origin id is always same
for a given subscription
ok
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
Hi,
On 14/07/2020 10:29, Amit Kapila wrote:
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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
As shown by Dilip, I don't think currently we have any way to prevent
this from changing during the transaction.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On 14/07/2020 11:36, Dilip Kumar wrote:
On Tue, Jul 14, 2020 at 2:47 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
Hi,
On 14/07/2020 10:29, Amit Kapila wrote:
On Tue, Jul 14, 2020 at 12:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek <petr@2ndquadrant.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 xidActually, 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/
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 xidActually, 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