Kevin Grittner wrote: > I've been reviewing code to get a better handle on the scope of > changes to support serializable transactions, in preparation for > next month's meetings with our CIO. My posts should start getting > progressively less hand-wavy. :-) > > I've come to a few conclusions: > > (1) The notions of having multiple serializable implementations > (SSI, S2PL, OCC) which can be mapped as a configuration option is > really not worth it. The cases where S2PL or OCC beat SSI are too > narrow to be worth the effort, and the pluggable approach seems like > it would be much more invasive and destabilizing than just picking > one and doing it more directly.
Agreed. > (2) If we're going with SSI, it appears that it would be a very > good idea to define a third lock method (SIREAD_LOCKMETHOD perhaps) > for the SIREAD locks. For one thing, that could keep them out of > the way of normal conflict detection (they don't conflict with > anything, per se) and out of the way of deadlock detection, > including rearrangement of waiting transactions. For another, they > have a different life-cycle -- they must stick around (along with > some minimal transaction information) until all transactions with a > snapshot prior to their commit have completed. That seems cleaner > and easier with a separate lock method. I must be missing something but I thought the only problem with our existing snapshot system was that you could see a row updated after your snapshot was created, and that the solution to that was to abort the transaction that would see the new row. Can you tell me what I am missing? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers