On Mon, Mar 29, 2021 at 12:57 PM Markus Wanner <markus.wan...@enterprisedb.com> wrote: > > On 29.03.21 08:23, Amit Kapila wrote: > > On Mon, Mar 29, 2021 at 11:42 AM Amit Kapila <amit.kapil...@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.
