From: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
---|---|
To: | 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-01-24 12:10:35 |
Message-ID: | BF2827DCCE55594C8D7A8F7FFD3AB7713DDBC758@SZXEML508-MBX.china.huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11th June 2013, Markus Wanner wrote:
> >> Agreed. Postgres-R uses a CommitOrderId, which is very similar in
> >> concept, for example.
> >
> > Do you think having this snapshot scheme would be helpful for
> Postgres-R?
>
> Yeah, it could help to reduce patch size, after a rewrite to use such a
> CSN.
>
> >> Or why do you need to tell apart aborted from in-progress
> >> transactions by CSN?
> >
> > I need to detect aborted transactions so they can be discared during
> > the eviction process, otherwise the sparse array will fill up. They
> > could also be filtered out by cross-referencing uncommitted slots
> with
> > the procarray. Having the abort case do some additional work to make
> > xid assigment cheaper looks like a good tradeoff.
>
> I see.
>
> >>> Sparse buffer needs to be at least big enough to fit CSN slots for
> >>> the xids of all active transactions and non-overflowed
> >>> subtransactions. At the current level PGPROC_MAX_CACHED_SUBXIDS=64,
> >>> the minimum comes out at 16 bytes * (64 + 1) slots * 100 =
> backends
> >>> = 101.6KB per buffer, or 203KB total in the default configuration.
> >>
> >> A CSN is 8 bytes, the XID 4, resulting in 12 bytes per slot. So I
> >> guess the given 16 bytes includes alignment to 8 byte boundaries.
> Sounds good.
> >
> > 8 byte alignment for CSNs is needed for atomic if not something else.
>
> Oh, right, atomic writes.
>
> > I think the size could be cut in half by using a base value for CSNs
> > if we assume that no xid is active for longer than 2B transactions as
> > is currently the case. I didn't want to include the complication in
> > the first iteration, so I didn't verify if that would have any
> > gotchas.
>
> In Postgres-R, I effectively used a 32-bit order id which wraps around.
>
> In this case, I guess adjusting the base value will get tricky.
> Wrapping could probably be used as well, instead.
>
> > The number of times each cache line can be invalidated is bounded by
> > 8.
>
> Hm.. good point.
>
We are also planning to implement CSN based snapshot.
So I am curious to know whether any further development is happening on this.
If not then what is the reason?
Am I missing something?
Thanks and Regards,
Kumar Rajeev Rastogi
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2014-01-24 12:27:51 | Re: [bug fix] psql's \conninfo reports incorrect destination on Windows |
Previous Message | MauMau | 2014-01-24 12:00:07 | Re: [bug fix] psql's \conninfo reports incorrect destination on Windows |