On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> 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.
>
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.
> (Things get even more interesting if you take into account that users
> may reuse the same gid for different transactions.
>
Are you saying that users might use the same GID which we have
constructed internally (say by combining origin and xid: originid_xid)
and then there will be conflict while replaying such transactions?
> Lag between
> subscriptions could then lead to blocking between different origin
> transactions...)
>
Right and even for one subscription that can lead to blocking
transactions. But isn't it similar to what we get for a primary key
violation while replaying transactions? In that case, we suggest users
remove conflicting rows, so in such cases, we can recommend users to
commit/rollback such prepared xacts?
--
With Regards,
Amit Kapila.
