Re: Logical Replication vs. 2PC

From: Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(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-19 15:52:12
Message-ID: c1ba422c-3b30-3cc8-c279-ebf72b08b0ad@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18.03.21 10:45, Amit Kapila wrote:
> While reviewing/testing subscriber-side work for $SUBJECT [1], I
> noticed a problem that seems to need a broader discussion, so started
> this thread. We can get prepare for the same GID more than once for
> the cases where we have defined multiple subscriptions for
> publications on the same server and prepared transaction has
> operations on tables subscribed to those subscriptions. For such
> cases, one of the prepare will be successful and others will fail in
> which case the server will send them again. Once the commit prepared
> is done for the first one, the next prepare will be successful. Now,
> this is not ideal but will work.

That's assuming you're using the same gid on the subscriber, which does
not apply to all use cases. It clearly depends on what you try to
achieve by decoding in two phases, obviously.

We clearly don't have this issue in BDR, because we're using xids
(together with a node id) to globally identify transactions and
construct local (per-node) gids that don't clash.

(Things get even more interesting if you take into account that users
may reuse the same gid for different transactions. Lag between
subscriptions could then lead to blocking between different origin
transactions...)

Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2021-03-19 15:52:37 Re: create table like: ACCESS METHOD
Previous Message David Steele 2021-03-19 15:40:07 Re: psql \df choose functions by their arguments