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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
