From: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Ants Aasma <ants(at)cybertec(dot)at> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Markus Wanner <markus(at)bluegap(dot)ch> |
Subject: | Re: Proposal for CSN based snapshots |
Date: | 2014-05-13 05:08:19 |
Message-ID: | BF2827DCCE55594C8D7A8F7FFD3AB7713DDE95E7@SZXEML508-MBX.china.huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-05-13 06:03:10 | Re: 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT .. |
Previous Message | Noah Misch | 2014-05-13 03:11:02 | Re: A couple logical decoding fixes/patches |