On Sat, Mar 20, 2021 at 8:53 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner > > > <markus.wan...@enterprisedb.com> wrote: > > > > > So, I think you are using xid of publisher and origin_id of > > > subscription to achieve uniqueness because both will be accessible in > > > prepare and commit prepared. Right? If so, I think that will work out > > > here as well. But if we think to use xid generated on subscriber then > > > we need to keep some mapping of original GID sent by publisher and GID > > > generated by us (origin+xid of subscription) because, at commit > > > prepared time, we won't know that xid. > > > > I agree that if we use (publisher's xid + subscriber origin id) > > instead of GID, we can resolve this deadlock issue. > > > > Yeah, the two things to keep in mind with this solution as well are > (a) still it is possible that conflict can be generated if the user > has prepared the transaction with that name of subscriber, the chances > of which are bleak and the user can always commit/rollback the > conflicting GID; (b) the subscription has two publications at > different nodes and then there is some chance that both send the same > xid, again the chances of this are bleak. > > I think even though in the above kind of cases there is a chance of > conflict but it won't be a deadlock kind of situation. So, I guess it > is better to do this solution, what do you think? >
I have enhanced the patch for 2PC implementation on the subscriber-side as per the solution discussed here [1]. [1] - https://www.postgresql.org/message-id/CAA4eK1KvXA34S24My1qnRhOn%2Bw30b2FdGNNzqh1pm0ENveGJJw%40mail.gmail.com -- With Regards, Amit Kapila.