Re: The plan for FDW-based sharding

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The plan for FDW-based sharding
Date: 2016-03-01 19:23:40
Message-ID: 56D5EC3C.5030106@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-03-01 19:27:09 Re: PROPOSAL: Fast temporary tables
Previous Message Jim Nasby 2016-03-01 19:17:26 Re: PROPOSAL: Fast temporary tables