Attached is a patch for the next milestone on the Serializable wiki
page: changing the table-level predicate locks to SIREAD locks
without worrying about lifespan. (Implementing correct lifespan is
next.)
The result of not worrying about it is that they aren't cleaned up
at all, even when the
Jeff Davis pg...@j-davis.com wrote:
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote:
Hmm. Why would we use a GUC for this instead of an additional
option to BEGIN TRANSACTION?
I'm with you. I feel pretty strongly that we should not have
behavior-changing GUCs.
OK. I actually
On Fri, Jan 8, 2010 at 9:46 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Opinions?
I think anything you decide about how to invoke the different
isolation levels will be easy to change later to meet whatever the
consensus of the community is at that time. I wouldn't spend any time
or
Robert Haas robertmh...@gmail.com wrote:
I think anything you decide about how to invoke the different
isolation levels will be easy to change later to meet whatever the
consensus of the community is at that time. I wouldn't spend any
time or energy on it now. For purposes of your
On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
Given that each of these would be the best choice for some
transaction mixes, it might make sense to allow some mapping of the
four ANSI transaction isolation levels to strategies for
implementation. At the risk of generating some
Jeff Davis pg...@j-davis.com wrote:
I think we should document that REPEATABLE READ is SI, and
encourage people to use it rather than SERIALIZABLE if they want
SI. Also, document that SERIALIZABLE may be changed in the future
to be truly serializable, and that may have a performance penalty
On Thu, 2010-01-07 at 16:27 -0600, Kevin Grittner wrote:
Could you draft a proposed doc change? While my ideas have
sometimes influenced the docs, my words don't tend to make it, so
I'm probably not the best candidate to suggest something. (That's
not actually a shocker for me, since I'm a
Jeff Davis pg...@j-davis.com wrote:
I'm torn between thinking it would be good to spell it that way
and thinking that we should have
serializable_isolation_implementation GUC (or something to that
effect) which maps to an enumeration containing snapshot and
ssi. Opinions welcome, since
I'm torn between thinking it would be good to spell it that way and
thinking that we should have serializable_isolation_implementation
GUC (or something to that effect) which maps to an enumeration
containing snapshot and ssi. Opinions welcome, since I've put
that GUC at the top of my
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote:
Hmm. Why would we use a GUC for this instead of an additional option
to BEGIN TRANSACTION?
I'm with you. I feel pretty strongly that we should not have
behavior-changing GUCs.
I make an exception for compatibility GUCs where the eventual
Florian G. Pflug f...@phlo.org wrote:
I believe the hard part of implementing true serializability is
not the actual SSI or S2PL algorithm, but rather the necessary
predicate locking strategy.
So I think checking how InnoDB tackles that and how much of it's
code is invovled might give a
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
Serializable transaction isolation is attractive for shops with
active development by many programmers against a complex schema
because it guarantees data integrity with very little staff time
I
On Tue, 2009-12-29 at 11:50 -0600, Kevin Grittner wrote:
Would you be able to help with the development in any way?
Yes, I'd be willing to invest some time.
For an area of active research such as this, I obviously can't promise
much in the way of results. But I can help explore and implement
Jeff Davis wrote:
On Tue, 2009-12-29 at 11:50 -0600, Kevin Grittner wrote:
Would you be able to help with the development in any way?
Yes, I'd be willing to invest some time.
For an area of active research such as this, I obviously can't promise
much in the way of results. But I can help
For perspective: Since our current application framework is about
ten years old now, the Wisconsin State Courts System has put
together a Long-Term Application Development Group to review all
aspects of our development and production runtime environments. We
started by reviewing various aspect
On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
Serializable transaction isolation is attractive for shops with
active development by many programmers against a complex schema
because it guarantees data integrity with very little staff time --
I would like to see true serializability
On 28.12.09 18:54 , Kevin Grittner wrote:
To give some idea of the scope of development, Michael Cahill added
SSI to InnoDB by modifying 250 lines of code and adding 450 lines of
code; however, InnoDB already had the S2PL option and the prototype
implementation isn't as sophisticated as I feel
Jeff Davis pg...@j-davis.com wrote:
I don't know what you mean by get-a-new-snapshot strategy or
how it is different from the current read committed behavior.
Our current Read Committed level, if it blocks on a competing UPDATE
or DELETE, can provide a view of data which is based on a mix of
On Mon, Dec 28, 2009 at 11:20 PM, Florian G. Pflug f...@phlo.org wrote:
I believe the hard part of implementing true serializability is not the
actual SSI or S2PL algorithm, but rather the necessary predicate locking
strategy.
So I think checking how InnoDB tackles that and how much of it's
Greg Stark gsst...@mit.edu wrote:
Talking about the details of the conflict resolution algorithms
and the benefits of serializable mode to your development
methodology is all fantasy as long as you don't have any
approaches to solve actually being able to detect the conflicts in
the first
Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
I don't know what you mean by get-a-new-snapshot strategy or
how it is different from the current read committed behavior.
Our current Read Committed level, if it blocks on a competing UPDATE
or DELETE, can provide a view of
21 matches
Mail list logo
