On 05/12/2018 15:40, Alexey Bashtanov wrote:
One of the reasons could be the row already locked by another backend,
doing the same kind of an update or something different.
Are these updates performed in a longer transactions?
Nope, the transaction will just be updating one row at a time.
Can they hit the same row from two clients at the same time?
I've looked for evidence of this, but can't find any. Certainly nothing
running for 2-10s, queries against this table are normally a few hundred ms.
Is there any other write or select-for-update/share load on the table?
Not that I'm aware of. How would I go about getting metrics on problems
like these?
Have you tried periodical logging of the non-granted locks?
Try querying pg_stat_activity and pg_locks (possibly joined and maybe
repeatedly self-joined, google for it)
to get the backends that wait one for another while competing for to
lock the same row or object.
Is there any existing tooling that does this? I'm loath to start hacking
something up when I'd hope others have done a better job already...
Chris
