On Fri, Aug 22, 2014 at 7:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
You have not shown us the full sequence of events leading up to the deadlock failure, but I hypothesize that there were yet other transactions that updated that same row in the very recent past. That might allow there to be more than one tuple lock involved (ie, locks on different versions of the row), which would create some scope for a deadlock failure.
Well, showing all events is difficult due to parallelization of importer, but shouldn't "select for update" solve the problem of other locks?
The transactions are exactly as shown - select for update and then update.
