On Thu, Dec 31, 2009 at 12:10 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Greg Stark wrote: > >> Hm, this raises the issue that you'll have to figure out what >> should happen if two different transactions are using different >> isolation modes. Currently our two isolation modes only control >> behaviour within your transaction so they co-exist perfectly fine. >> >> ISTM you would need to have transactions in read-comitted and >> snapshot isolation modes recording what sets of records they read >> in order to be able to guarantee serializable transactions to make >> any guarantees as well. > > No, there is no requirement that serializable transactions serialize > with weaker modes. The Cahill thesis addresses this point directly. > Unless you can point out some flaw in his proofs, this is not an > issue. > >> [criticisms of hypothetical implementation techniques] > > There are no such proposals on the table, and the hypothetical > techniques you mention seem unlikely to be ones I would use. The one > and only issue I have on the table at the moment is to create a new > lock method for SIREAD locks. I'd welcome any comments on that. If > I get to the point of feeling comfortable with that, I'll move > forward to other issues.
Kevin, I think I understand why you're trying to break this down into manageable pieces, but I don't think it's really possible to have this conversation in isolation. If your question is "Could it ever be acceptable to add a new lock mode?" then I answer "yes". And I am pretty confident that this will also be the consensus view. But if your question is "Does it make sense to handle SIREAD locks as a new lock mode?" then I answer "I don't know, because I haven't seen the whole design yet". You just can't answer a question like this in isolation. It seems to me that the hard part of this problem is to describe the general mechanism by which conflicts will be detected, with specific references to the types of data structures that will be used to hold that information. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
