Re: [PATCH] Provide more information to filter_prepare - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [PATCH] Provide more information to filter_prepare
Date
Msg-id CAA4eK1JLECUY6rQOgs5bdzFy7BHkrqo1SskyBH+V9h2LwYkzcw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Provide more information to filter_prepare  (Markus Wanner <markus.wanner@enterprisedb.com>)
Responses Re: [PATCH] Provide more information to filter_prepare  (Markus Wanner <markus.wanner@enterprisedb.com>)
List pgsql-hackers
On Mon, Mar 29, 2021 at 3:11 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> On 29.03.21 11:13, Amit Kapila wrote:
> > 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.
>
> I think you are misunderstanding.  This is about a globally unique
> identifier for a transaction, which has nothing to do with a GID used to
> prepare a transaction.  This *needs* to be the same for what logical is
> the same transaction.
>

Okay, but just in the previous sentence ("However, reuse of the same
<parameter>gid</parameter> for example by a downstream node using
multiple subscriptions may lead to it not being a unique
identifier."), you have explained how sending a GID identifier can
lead to a non-unique identifier for multiple subscriptions. And then
in the next line, the way you are suggesting to generate GID by use of
XID seems to have the same problem, so that caused confusion for me.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: Markus Wanner
Date:
Subject: Re: [PATCH] add concurrent_abort callback for output plugin