On Mon, Mar 29, 2021 at 3:30 PM Markus Wanner <
markus.wanner@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
