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

From Adrian Klaver
Subject Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Date
Msg-id 53F78CF0.6070907@aklaver.com
Whole thread Raw
In response to Re: deadlock in single-row select-for-update + update scenario? How could it happen?  (hubert depesz lubaczewski <depesz@gmail.com>)
Responses Re: deadlock in single-row select-for-update + update scenario? How could it happen?  (hubert depesz lubaczewski <depesz@gmail.com>)
List pgsql-general
On 08/22/2014 11:14 AM, hubert depesz lubaczewski wrote:
> On Fri, Aug 22, 2014 at 7:54 PM, Adrian Klaver
> <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.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.klaver@aklaver.com


pgsql-general by date:

Previous
From: Jerry Sievers
Date:
Subject: Re: Restart replicated slave procedure
Next
From: Joseph Kregloh
Date:
Subject: Re: Restart replicated slave procedure