I wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> wrote:
>> This thread has really been one of those cases where everyone
>> thought they were having a different kind of discussion.
>
> Apparently so.
In light of discussions at PGCon, I'm going to abandon this thread in
favor of a discussion of what this feature would look like from a user
perspective. Only after there is consensus (if any) on the
desirability of the behavior will I move on to a discussion of
implementation techniques -- probably on a fresh thread.
For the record, it became clear that I did a bad job of communicating
on this thread, so I'll finish it with some clarifications and
observations "just for the record."
First, the paper didn't propose any new techniques for predicate
locking, other than using a lock level which doesn't block anything
else. It did reference existing papers on locking techniques.
Second, Robert Haas had an interesting insight: if the techniques from
the paper were implemented in the absence of predicate locks, that
would still reduce the frequency of serialization anomalies from
current snapshot isolation techniques. Since the PostgreSQL community
generally prefers incremental enhancement patches on the way to a
final result, he suggested that this would be a good path -- do
everything except the predicate locks, show the incremental benefits,
then add the predicate locks. We could probably even add the
predicate locks in stages: first implement table level predicate
locks, since that has to exist and would provide a complete, if
somewhat clumsy, serializable solution; then move on to more
fine-grained locks. It would probably be workable, and possibly
optimal, to have just table and page locks; although it seems likely
that index range locks and row locks would also be worth it,
eventually.
But all that is just to get it on the record; I'm getting ahead of
myself here. I'll be posting on the user-facing aspects of this soon.
-Kevin