On Sat, Mar 20, 2021 at 8:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> > > <markus.wanner@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.
