> On 1 May 2018, at 22:43, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I'm concerned about the provisioning aspect of this problem. Suppose
> I have two existing database systems with, perhaps, wildly different
> XID counters. On a certain date, I want to start using this system.
Yes, that totally possible. On both systems you need:
* set track_global_snapshots='on' -- this will start writing each
transaction commit sequence number to SRLU.
* set global_snapshot_defer_time to 30 seconds, for example -- this
will delay oldestXmin advancement for specified amount of time,
preserving old tuples.
* restart database
* optionally enable NTPd if it wasn't enabled.
Also it is possible to avoid reboot, but that will require some careful
work: after enabling track_global_snapshots it will be safe to start
global transactions only when all concurrently running transactions
will finish. More or less equivalent thing happens during logical slot
creation.
> Or conversely, I have two systems that are bonded together using this
> system from the beginning, and then, as of a certain date, I want to
> break them apart into two standalone systems. In your proposed
> design, are things like this possible? Can you describe the setup
> involved?
Well, they are not actually "bonded" in any persistent way. If there will
be no distributed transactions, there will be no any logical or physical
connection between that nodes.
And returning to your original concern about "wildly different XID
counters" I want to emphasise that only thing that is floating between
nodes is a GlobalCSN's during start and commit of distributed transaction.
And that GlobalCSN is actually a timestamp of commit, the real one, from
clock_gettime(). And clock time is supposedly more or less the same
on different nodes in normal condition. But correctness here will not
depend on degree of clock synchronisation, only performance of
global transactions will.
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
