Re: The plan for FDW-based sharding
От | Konstantin Knizhnik |
---|---|
Тема | Re: The plan for FDW-based sharding |
Дата | |
Msg-id | 56D5EC3C.5030106@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: The plan for FDW-based sharding (Petr Jelinek <petr@2ndquadrant.com>) |
Список | pgsql-hackers |
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 unclearto me - what happens when user changes the XTM plugin on the server? I didn't see any xid handover API which makesme wonder if > changes of a plugin (or for example failure to load previously used plugin due to admin error) will send server to similarsituation as xid wraparound. > Transaction manager is very "intimate" part of DBMS and certainly bugs and problems in custom TM implementation can breakthe 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 still32-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 wraparoundin this case is handled in standard way. Instead of assigning own global XIDs, pg_tsdtm provides mapping betweenlocal 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
В списке pgsql-hackers по дате отправления: