On Sat, Mar 20, 2021 at 2:57 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> On 20.03.21 03:17, Amit Kapila wrote:
> > Are you saying that users might use the same GID which we have
> > constructed internally (say by combining origin and xid: originid_xid)
> > and then there will be conflict while replaying such transactions?
>
> No, I was pondering about a user doing (in short sequence):
>
> ..
> PREPARE TRANSACTION 'foobar';
> COMMIT PREPARED 'foobar';
>
> BEGIN;
> ...
> PREPARE TRANSACTION 'foobar';
> COMMIT PREPARED 'foobar';
>
> > Right and even for one subscription that can lead to blocking
> > transactions. But isn't it similar to what we get for a primary key
> > violation while replaying transactions?
>
> Sure, it's a conflict that prevents application. A primary key conflict
> may be different in that it does not eventually resolve, though.
>
> > In that case, we suggest users
> > remove conflicting rows, so in such cases, we can recommend users to
> > commit/rollback such prepared xacts?
>
> Right, if you use gids, you could ask the user to always provide unique
> identifiers and not reuse them on any other node. That's putting the
> burden of coming up with unique identifiers on the user, but that's a
> perfectly fine and reasonable thing to do. (Lots of other systems out
> there requiring a unique request id or such, which would get confused if
> you issue requests with duplicate ids.)
>
Right, but I guess in our case using user-provided GID will conflict
if we use multiple subscriptions on the same node. So, it is better to
generate a unique identifier like we are discussing here, something
like (origin_id of subscription + xid of the publisher). Do you see
any problem with that?
--
With Regards,
Amit Kapila.
