On 2019-Jun-14, Alvaro Herrera wrote: > I think there are worse problems here. I tried the attached isolation > spec. Note that the only difference in the two permutations is that s0 > finishes earlier in one than the other; yet the first one works fine and > the second one hangs until killed by the 180s timeout. (s3 isn't > released for a reason I'm not sure I understand.)
Actually, those behaviors both seem correct to me now that I look closer. So this was a false alarm. In the code before de87a084c0, the first permutation deadlocks, and the second permutation hangs. The only behavior change is that the first one no longer deadlocks, which is the desired change. I'm still trying to form a case to exercise the case of skip_tuple_lock having the wrong lifetime. The fact that both permutations behave differently, even though the only difference is where s0 commits relative to the s3_share step, is an artifact of our unusual tuple locking implementation. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
