Re: Global snapshots - Mailing list pgsql-hackers

From Stas Kelvich
Subject Re: Global snapshots
Date
Msg-id D963AFAB-1FA5-4FE7-A5A2-AC37D728564C@postgrespro.ru
Whole thread Raw
In response to Re: Global snapshots  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Global snapshots  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

> On 4 May 2018, at 22:09, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> So, is the idea that we'll definitely find out about any remote
> transactions within 30 seconds, and then after we know about remote
> transactions, we'll hold back OldestXmin some other way?

Yes, kind of. There is a procArray->global_snapshot_xmin variable which
acts as a barrier to xmin calculations in GetOldestXmin and
GetSnapshotData, when set.

Also each second GetSnapshotData writes globalxmin (as it was before
procArray->global_snapshot_xmin was taken into account) into a circle
buffer with a size equal to global_snapshot_defer_time value. That more
or less the same thing as with Snapshot Too Old feature, but with a
bucket size of 1 second instead of 1 minute.
procArray->global_snapshot_xmin is always set to oldest
value in circle buffer.

This way xmin calculation is always gives a value that were
global_snapshot_xmin seconds ago and we have mapping from time (or
GlobalCSN) to globalxmin for each second in this range. So when
some backends imports global snapshot with some GlobalCSN, that
GlobalCSN is mapped to a xmin and this xmin is set as a Proc->xmin.

--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement
Next
From: Shay Rojansky
Date:
Subject: Re: citext function overloads for text parameters