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

On 08/22/2014 11:14 AM, hubert depesz lubaczewski wrote:
> On Fri, Aug 22, 2014 at 7:54 PM, Adrian Klaver
> <adrian(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> Which in itself might be a clue.
>
> Is all the code/data running on/coming from that machine or is some
> coming in remotely?
>
> Where network latency might be an issue?
>
>
> All locally, but hey - how could network latency be a problem?
> Transaction gets the lock on row, and then it updates. the same row. in
> the same transaction. with nothing else in the transaction. where is
> here place for deadlock for another, identical transaction?

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?

>
> depesz

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com