Jeff Davis <pgsql@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
