On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner <markus.wan...@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.
