Re: Logical Replication vs. 2PC

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, osumi(dot)takamichi(at)fujitsu(dot)com
Subject: Re: Logical Replication vs. 2PC
Date: 2021-03-20 15:23:46
Message-ID: CAA4eK1LTNrFt7=0sc-Kge6mX+k7YAixEzLy0xG7wDDpgSbHHmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> > <markus(dot)wanner(at)enterprisedb(dot)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 was also
> thinking that is it okay to change the prepared transaction name on
> the subscriber? I mean instead of GID if we use some other name then
> imagine a case where a user has prepared some transaction on the
> publisher and then tries to commit that on the subscriber using the
> prepared transaction name, then it will not work. But maybe this is
> not really a practical use case. I mean why anyone would want to
> prepare a transaction on the publisher and commit that prepared
> transaction directly on the subscriber.
>

It is not clear to me either if for such a purpose we need to use the
same GID as provided by the publisher. I don't know if there is any
such use case but if there is one, maybe later we can provide an
option with a subscription to use GID provided by the publisher when
two_phase is enabled?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-20 15:39:34 Re: [HACKERS] Custom compression methods
Previous Message Tom Lane 2021-03-20 15:23:19 Re: pg_upgrade failing for 200+ million Large Objects