Re: deadlock in single-row select-for-update + update scenario? How could it happen?

On Fri, Aug 22, 2014 at 8:33 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> Not sure, just the combination of parallel operations and remote
> connections seemed to be an avenue to explore. Given that everything is
> local, turns out it was dead end.
> Looking at the pastebin log again, am I reading it right that the first
> process actually COMMITs properly?
> Also is there a trigger in the mix that might be fouling things up?
>

Please note that the pastebin log is split by backend pid, and only in
backend-pid groups sorted by timestamp.

66014 started transaction later, and committed, while 66017, which started
transaction earlier, and actually obtained lock earlier - got killed by
deadlock resolution.

There are no triggers aside from some (~10) fkeys.

depesz