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. > What we do need is for the commit prepared > message to remember what the xid of the prepare was and then re-find > it using the commit WAL record's twophase_xid field. So we don't need > to add GID to any WAL records, nor to any in-memory structures. Other part of the story is how to find GID during decoding of commit prepared record. I did that by adding GID field to the commit WAL record, because by the time of decoding all memory structures that were holding xid<->gid correspondence are already cleaned up. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
