| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
|---|---|
| To: | hubert depesz lubaczewski <depesz(at)gmail(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 19:21:14 | 
| Message-ID: | 20140822192114.GO6343@eldon.alvh.no-ip.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-08-22 19:26:59 | Re: WAL log level compatibility | 
| Previous Message | Joseph Kregloh | 2014-08-22 19:18:36 | Re: Restart replicated slave procedure |