Re: The plan for FDW-based sharding - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: The plan for FDW-based sharding
Date
Msg-id 56D5EC3C.5030106@postgrespro.ru
Whole thread Raw
In response to Re: The plan for FDW-based sharding  (Petr Jelinek <petr@2ndquadrant.com>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: PROPOSAL: Fast temporary tables
Next
From: Pavel Stehule
Date:
Subject: Re: PROPOSAL: Fast temporary tables