On Mon, Mar 29, 2021 at 3:30 PM Markus Wanner <
markus.wan...@enterprisedb.com> wrote:
>
> On 29.03.21 11:53, Amit Kapila wrote:
> > 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.
>
> Maybe the example of the downstream node is a bad one. I understand
> that can cause confusion. Let's leave away that example and focus on
> the output plugin side. v6 attached.
>
> > 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.
>
> It was not intended as a suggestion for how to generate GIDs at all.
> Hopefully leaving away that bad example will make it less likely to
> appear related to GID generation on the subscriber.
Thanks for the updated patch. Patch applies neatly, make check and make
check-world passes. The code changes look fine to me.
In documentation, I did not understand the bold contents in the below
documentation:
+ The <parameter>ctx</parameter> parameter has the same contents as
for
+ the other callbacks. The parameters <parameter>xid</parameter>
+ and <parameter>gid</parameter> provide two different ways to
identify
+ the transaction. For some systems, the <parameter>gid</parameter>
may
+ be sufficient. However, reuse of the same
<parameter>gid</parameter>
+ may lead to it not being a unique identifier.
*Therefore, other systems+ combine the <parameter>xid</parameter>
with an identifier of the origin+ node to form a globally unique
transaction identifier.* The later
+ <command>COMMIT PREPARED</command> or <command>ROLLBACK
+ PREPARED</command> carries both identifiers, providing an output
plugin
+ the choice of what to use.
I know that in publisher/subscriber decoding, the prepared transaction
gid will be modified to either pg_xid_origin or pg_xid_subid(it is still
being discussed in logical decoding of two-phase transactions thread, it
is in not yet completely finalized) to solve the subscriber getting the
same gid name.
But in prepare_filter_cb callback, by stating "other systems ..." it is not
very clear who will change the GID. Are we referring to
publisher/subscriber decoding?
Regards,
Vignesh
