On 12 May 2014 19:27, Heikki Linnakangas Wrote:
> On 01/24/2014 02:10 PM, Rajeev rastogi wrote:
> > We are also planning to implement CSN based snapshot.
> > So I am curious to know whether any further development is happening
> on this.
>
> I started looking into this, and plan to work on this for 9.5. It's a
> big project, so any help is welcome. The design I have in mind is to
> use the LSN of the commit record as the CSN (as Greg Stark suggested).
Great !
> Some problems and solutions I have been thinking of:
>
> The core of the design is to store the LSN of the commit record in
> pg_clog. Currently, we only store 2 bits per transaction there,
> indicating if the transaction committed or not, but the patch will
> expand it to 64 bits, to store the LSN. To check the visibility of an
> XID in a snapshot, the XID's commit LSN is looked up in pg_clog, and
> compared with the snapshot's LSN.
Isn't it will be bit in-efficient to look in to pg_clog to read XID's commit
LSN for every visibility check?
> With this mechanism, taking a snapshot is just a matter of reading the
> current WAL insertion point. There is no need to scan the proc array,
> which is good. However, it probably still makes sense to record an xmin
> and an xmax in SnapshotData, for performance reasons. An xmax, in
> particular, will allow us to skip checking the clog for transactions
> that will surely not be visible. We will no longer track the latest
> completed XID or the xmin like we do today, but we can use
> SharedVariableCache->nextXid as a conservative value for xmax, and keep
> a cached global xmin value in shared memory, updated when convenient,
> that can be just copied to the snapshot.
I think we can update xmin, whenever transaction with its XID equal
to xmin gets committed (i.e. in ProcArrayEndTransaction).
Thanks and Regards,
Kumar Rajeev Rastogi