On Thu, Jul 9, 2020 at 2:41 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Wed, Jul 8, 2020 at 3:32 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > Only replying to the replication origin point, other comment looks > fine to me so I will work on those. > > > Replication Origins > > ------------------------------ > > I think we also need to conclude on origins related discussion [1]. > > As far as I can see, the origin_id can be sent with the first startup > > 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 it earlier then we need to record it with other WAL > > records. The point is that those are set with > > pg_replication_origin_xact_setup but not sure how and when that > > function is called. > > pg_replication_origin_xact_setup is exposed function so this will > allow a user to set an origin for their session so that all the > operation done from that session will be marked by that origin id. >
Hmm, I think that can be done by pg_replication_origin_session_setup. > And the clear use case for this is to avoid sending such transactions > by suing FilterByOrigin. But I am not sure about the point that we > discussed at [1] that what is the use of the origin and origin_lsn we > send at pgoutput_begin_txn. > I could see the use of 'origin' with FilterByOrigin but not sure how origin_lsn can be used? > The other alternative is that we can ignore that > > for now and once the usage is clear we can enhance it. What do you > > think? > > That seems like a sensible option to me. > I have responded to that another thread. Let us see if someone responds to it. Feel free to add if you have some points related to that thread. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
