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

From: hubert depesz lubaczewski <depesz(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Date: 2014-08-22 18:14:58
Message-ID: CAKrjmhcW97_Mivy-5-JuUXExgJ3ZOXLJeE3G5B5x_Xpe8tK+Lw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Aug 22, 2014 at 7:54 PM, Adrian Klaver <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?

depesz

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jerry Sievers 2014-08-22 18:21:45 Re: Restart replicated slave procedure
Previous Message Adrian Klaver 2014-08-22 17:54:25 Re: deadlock in single-row select-for-update + update scenario? How could it happen?