Kevin Grittner wrote: >> 1. implementation of the paper's technique sans predicate locking, >> that would avoid more serialization anomalies but not all? > > I saw that as a step along the way to support for fully serializable > transactions. If covered by a "migration path" GUC which defaulted to > current behavior, it would allow testing of all of the code except the > predicate lock tracking (before the predicate locking code was > created), in order to give proof of concept, check performance impact > of that part of the code, etc. I wasn't thinking that it would be a > useful long-term option without the addition of the predicate locks.
I cannot prove it, but I have a feeling that the impact on performance and concurrency will be considerably higher for an implementation with predicate locks. Every WHERE-clause in a SELECT will add one or more checks for each concurrent writer. So while I think it is a good idea to approach full serializability in a step-by-step approach, it would be wise to consider the possibility that we will not reach the goal (because implementing predicate locks might be too difficult or the result perform too badly). So any intermediate step should be useful in itself, unless we are ready to rip out the whole thing again. What would be the useful intermediate steps in this case? From the user perspective, will an implementation of the paper's approach as an intermediate step provide a useful and understandable isolation level? Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
