On Mon, Mar 29, 2021 at 12:57 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> On 29.03.21 08:23, Amit Kapila wrote:
> > On Mon, Mar 29, 2021 at 11:42 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > What exactly is the node identifier here? Is it a publisher or
> > subscriber node id? We might want to be a bit more explicit here?
>
> Good point. I clarified this to speak of the origin node (given this is
> not necessarily the direct provider when using chained replication).
>
This might or might not be valid for all logical replication solutions
but in the publisher-subscriber model, it would easily lead to
duplicate identifiers and block the replication. For example, when
there are multiple subscriptions (say - 2) for multiple publications
(again say-2), the two subscriptions are on Node-B and two
publications are on Node-A. Say both publications are for different
tables tab-1 and tab-2. Now, a prepared transaction involving
operation on both tables will generate the same GID. This will block
forever if someone has set synchronous_standby_names for both
subscriptions because Prepare won't finish till both the subscribers
prepare the transaction and due to conflict one of the subscriber will
never finish the prepare. I thought it might be better to use
subscriber-id (or unique replication-origin-id for a subscription) and
the origin node's xid as that will minimize the chances of any such
collision. We can reach this situation if the user prepares the
transaction with the same name as we have generated but we can suggest
user not to do this or we can generate an internal prepared
transaction name starting with pg_* and disallow prepared transaction
names from the user starting with pg_ as we do in some other cases.
--
With Regards,
Amit Kapila.
