Tom, thanks for inspecting the patch. There's so many problems that slipped from my attention... But one thing that bothers me most is the problem with predicate locking
> 13 марта 2018 г., в 0:55, Tom Lane <t...@sss.pgh.pa.us> написал(а): > > The PredicateLockPage call also troubles me quite a bit, not only from > a modularity standpoint but because that implies a somewhat-user-visible > behavioral change when this optimization activates. People who are using > serializable mode are not going to find it to be an improvement if their > queries fail and need retries a lot more often than they did before. > I don't know if that problem is bad enough that we should disable skipping > when serializable mode is active, but it's something to think about. Users already have to expect this if the scan turns into IoS somewhat accidentally. There will be page predicate locks with possible false positive conflicts. I'm not sure that keeping existing tuple-level lock granularity is necessary. I think we can do it if we introduce PredicateLockTuple that do not require tuple's xmin, that takes only tid and does not look into heap. But this tweak seems outside of the patch scope and I believe it's better avoid messing with SSI internals without strong reason. Best regards, Andrey Borodin.