From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <grimkg(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, drkp(at)csail(dot)mit(dot)edu, Kevin(dot)Grittner(at)wicourts(dot)gov |
Subject: | Re: Serializable Snapshot Isolation |
Date: | 2010-09-23 05:21:01 |
Message-ID: | 4C9AE3BD.6010109@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23/09/10 02:14, Kevin Grittner wrote:
> There is a rub on the other point, though. Without transaction
> information you have no way of telling whether TN committed before
> T0, so you would need to assume that it did. So on this count,
> there is bound to be some increase in false positives leading to
> transaction rollback. Without more study, and maybe some tests, I'm
> not sure how significant it is. (Actually, we might want to track
> commit sequence somehow, so we can determine this with greater
> accuracy.)
I'm confused. AFAICS there is no way to tell if TN committed before T0
in the current patch either.
> But wait, the bigger problems are yet to come.
>
> The other way we can detect conflicts is a read by a serializable
> transaction noticing that a different and overlapping serializable
> transaction wrote the tuple we're trying to read. How do you
> propose to know that the other transaction was serializable without
> keeping the SERIALIZABLEXACT information?
Hmm, I see. We could record which transactions were serializable in a
new clog-like structure that wouldn't exhaust shared memory.
> And how do you propose to record the conflict without it?
I thought you just abort the transaction that would cause the conflict
right there. The other transaction is committed already, so you can't do
anything about it anymore.
> Finally, this would preclude some optimizations which I *think* will
> pay off, which trade a few hundred kB more of shared memory, and
> some additional CPU to maintain more detailed conflict data, for a
> lower false positive rate -- meaning fewer transactions rolled back
> for hard-to-explain reasons. This more detailed information is also
> what seems to be desired by Dan S (on another thread) to be able to
> log the information needed to be able to reduce rollbacks.
Ok, I think I'm ready to hear about those optimizations now :-).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-09-23 06:09:20 | Re: Git cvsserver serious issue |
Previous Message | Robert Haas | 2010-09-23 04:28:44 | Re: security label support, revised |