From: Stas Kelvich <s.kelvich@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Global snapshots
Date: Wed, 2 May 2018 00:02:47 +0300
Message-ID: <5A30884C-F446-40FD-9D86-F4046F29F9F6@postgrespro.ru> (raw)
In-Reply-To: <CA+TgmoazjBL1D-hSV-pMYK=g9L-Zc3v0Gh7TiAhMYRzo6nXdSg@mail.gmail.com>
References: <21BC916B-80A1-43BF-8650-3363CCDAE09C@postgrespro.ru>
<CA+TgmoazjBL1D-hSV-pMYK=g9L-Zc3v0Gh7TiAhMYRzo6nXdSg@mail.gmail.com>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: s.kelvich@postgrespro.ru, robertmhaas@gmail.com
Subject: Re: Global snapshots
In-Reply-To: <5A30884C-F446-40FD-9D86-F4046F29F9F6@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox