RE: Wrong FOR UPDATE lock type

> 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