> Well, there is a theoretical chance of deadlock --- not against other
> transactions doing the same thing, since RowShareLock and
> RowExclusiveLock don't conflict, but you could construct deadlock
> scenarios involving other transactions that grab ShareLock or
> ShareRowExclusiveLock. So I don't think it's appropriate for the
> "deadlock risk" check to ignore RowShareLock->RowExclusiveLock
> upgrades.
There is theoretical chance of deadlock when two xactions lock
tables in different order and we can check this only in deadlock
detection code.
> But I'm not sure the check should be enabled in production releases
> anyway. I just put it in as a quick and dirty debug check. Perhaps
> it should be under an #ifdef that's not enabled by default.
No reason to learn users during transaction processing. We need in
good deadlock detection code and documentation.
Vadim