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

From Alvaro Herrera
Subject Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Date
Msg-id 20140822192114.GO6343@eldon.alvh.no-ip.org
Whole thread Raw
In response to 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
hubert depesz lubaczewski wrote:
> I have developer with pg 9.3.5, which is reporing something really strange.
>
> He runs importer, which does, in single transaction:
>
> begin;
> select * from table where pkey = <value> limit 1 for update;
> update table set ... where pkey = <the same_value>;
> commit;
>
> and two backends running the same transaction deadlock.

FWIW this problem was reported also by Andrew Sackville-West at
http://www.postgresql.org/message-id/20140731233051.GN17765@andrew-ThinkPad-X230

I strongly suspect now that the problem is related to the locking of
updated versions as heap_lock_tuple_updated, and perhaps the internal
locking done by EvalPlanQual.  Haven't traced through it.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


pgsql-general by date:

Previous
From: Joseph Kregloh
Date:
Subject: Re: Restart replicated slave procedure
Next
From: Bruce Momjian
Date:
Subject: Re: WAL log level compatibility