Jeff Davis <pg...@j-davis.com> 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. Arguably, it would actually be a very weak partial implemenation of predicate locking, in that it would get a non-blocking lock on tuples viewed, up to some limit. At the point where we added an escalation to table locking for the limit, started with the table lock when we knew it was a table scan, and locked the index range for an index scan, we would actually have achieved fully serializable transactions. > 2. various granularities of predicate locking? I haven't seen that configurable by transaction, and I'm not entirely sure that would make sense. I have seen products where a default granularity was set with the equivalent of a global GUC, and it could be overridden for particular tables. I see such a setting as the default for access to rows accessed through indexes. If there is a table scan, the lock would have to start at the table level, regardless of settings. If too many locks accrue for one transaction against a table at one granularity, those locks would need to be consolidated to a coarser granularity to avoid exhausting lock tracking space in RAM. We're slipping into implementation details here, but I'm not sure how we can discuss the GUCs needed without at least touching on that.... -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers