On 5 January 2017 at 10:21, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > Thank you for looking into this. > >> On 5 Jan 2017, at 09:43, Simon Riggs <si...@2ndquadrant.com> wrote: >>> >>> GID is now variable sized. You seem to have added this to every >>> commit, not just 2PC >> > > Hm, didn’t realise that, i’ll fix. > >> I've just realised that you're adding GID because it allows you to >> uniquely identify the prepared xact. But then the prepared xact will >> also have a regular TransactionId, which is also unique. GID exists >> for users to specify things, but it is not needed internally and we >> don't need to add it here. > > I think we anyway can’t avoid pushing down GID to the client side. > > If we will push down only local TransactionId to remote server then we will > lose mapping > of GID to TransactionId, and there will be no way for user to identify his > transaction on > second server. Also Open XA and lots of libraries (e.g. J2EE) assumes that > there is > the same GID everywhere and it’s the same GID that was issued by the client. > > Requirements for two-phase decoding can be different depending on what one > want > to build around it and I believe in some situations pushing down xid is > enough. But IMO > dealing with reconnects, failures and client libraries will force programmer > to use > the same GID everywhere.
Surely in this case the master server is acting as the Transaction Manager, and it knows the mapping, so we are good? I guess if you are using >2 nodes then you need to use full 2PC on each node. But even then, if you adopt the naming convention that all in-progress xacts will be called RepOriginId-EPOCH-XID, so they have a fully unique GID on all of the child nodes then we don't need to add the GID. Please explain precisely how you expect to use this, to check that GID is required. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
