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