| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | hubert depesz lubaczewski <depesz(at)gmail(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, 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 17:49:56 |
| Message-ID: | 4401.1408729796@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
hubert depesz lubaczewski <depesz(at)gmail(dot)com> writes:
> On Fri, Aug 22, 2014 at 6:45 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
> wrote:
>> So process 66017 and 66014 are blocking each because they are running the
>> exact same queries. The interesting part is the process with the lower pid
>> is starting later then the none with the higher pid.
> Locking is obvious. But why deadlock? There is just single row, and it
> shouldn't be able to deadlock on it?!
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2014-08-22 17:50:44 | Re: deadlock in single-row select-for-update + update scenario? How could it happen? |
| Previous Message | Adrian Klaver | 2014-08-22 17:43:00 | Re: deadlock in single-row select-for-update + update scenario? How could it happen? |