On Sat, Mar 20, 2021 at 2:57 PM Markus Wanner <markus.wan...@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.
