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
predicatelocking
> 13 марта 2018 г., в 0:55, Tom Lane <tgl@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
withpossible 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
notlook into heap. But this tweak seems outside of the patch scope and I believe it's better avoid messing with SSI
internalswithout strong reason.
Best regards, Andrey Borodin.
