Greg Stark <st...@enterprisedb.com> wrote: > Well I don't understand what storing locks in an index can > accomplish if other queries might use other indexes or sequential > scans to access the records and never see those locks. > > Or does this method only require that writers discover the locks and > therefore only writers can ever fail due to serialization failures > they cause? Well, readers don't need to find the SIREAD locks which readers set. Conflicts between writers are handled the same as current PostgreSQL techniques. Readers need to look for write locks, and writers need to look for SIREAD locks. Neither is blocked by the other, but finding a conflict sets both transactions with a directional "edge" boolean flag. (So we would need to track two booleans per transaction in addition to the new SIREAD locks.) When a transaction reaches a state where both "edge" booleans are set, one of the two transactions involved in setting that must be rolled back. The prototype implementation in the Berkeley DB preferred to roll back a "pivot" transaction (one with both edges set) where possible, so the failure would probably usually be on a transaction which modified data, but not necessarily -- if the writers involved have committed and the reader transaction might see an invalid database state, the reader would be rolled back. > I still haven't actually read the paper so I should probably bow out > from the conversation until I do. I was apparently already under > one misapprehension as Laurenz just claimed the paper does not show > how to prevent "phantoms" (phantom reads I assume?). Perhaps it's > not as ambitious as achieving true serializability after all? It does achieve true serializability in terms of the definitions I've read, although I've discovered at least one way in which its guarantees aren't as strong as traditional blocking techniques -- it doesn't guarantee that transactions at a level less strict than serializable will see a state which would exist between some serial execution of serializable transactions which modify the data, as the blocking schemes do. As I said in an earlier post, I'm OK with that, personally. We should probably document it as a difference, to alert someone converting, but the standard doesn't seem to require the behavior that traditional blocking approaches provide on this point. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers