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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +