On 03/01/2016 09:19 PM, Petr Jelinek wrote:
Since this thread heavily discusses the XTM, I have question about the XTM as proposed because one thing is very unclear to me - what happens when user changes the XTM plugin on the server? I didn't see any xid handover API which makes me wonder if
changes of a plugin (or for example failure to load previously used plugin due to admin error) will send server to similar situation as xid wraparound.
Transaction manager is very "intimate" part of DBMS and certainly bugs and
problems in custom TM implementation can break the server.
So if you are providing custom TM implementation, you should take full
responsibility on system integrity.
XTM API itself doesn't enforce any XID handling policy. As far as we do not
want to change tuple header format, XID is still 32-bit integer.
In case of pg_dtm, global transactions at all nodes are assigned the same XID
by arbiter. Arbiter is handling XID wraparound.
In pg_tsdtm each node maintains its own XIDs, actually pg_tsdtm doesn't change way of assigning CIDs by Postgres. So wraparound in this case is handled in standard way. Instead of assigning own global XIDs, pg_tsdtm provides mapping between local XIDs and
global CSNs. Visibility checking rules looks on CSNs, not on XIDs.
In both cases if system is for some reasons restarted and DTM plugin failed to
be loaded, you can still access database locally. No data can be lost.
--
Konstantin Knizhnik
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
