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. (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. Thoughts? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers