Re: Can two “SELECT FOR UPDATE” statements on the same table cause a deadlock?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve A <golfmat1(at)yahoo(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Can two “SELECT FOR UPDATE” statements on the same table cause a deadlock?
Date: 2012-10-11 02:09:53
Message-ID: 16757.1349921393@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steve A <golfmat1(at)yahoo(dot)com> writes:
> In a nutshell, I'm curious about the order in which PG will lock rows during a SELECT FOR UPDATE. If two simultaneous SELECT FOR UPDATE statements select intersecting rows from the same table, can PG be relied upon to lock the rows in a consistent manner that always avoids deadlock (e.g. in order of ascending primary key)?

Only if you use ORDER BY in each such query to constrain the rows to be
locked in the same order. You probably want to spend some time perusing
the fine manual very carefully:
http://www.postgresql.org/docs/9.2/static/sql-select.html#SQL-FOR-UPDATE-SHARE

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sean Chittenden 2012-10-11 03:03:26 Re: 'full_page_writes=off' , VACUUM and crashing streaming slaves...
Previous Message Tom Lane 2012-10-11 01:24:32 Re: Planner chooses multi-column index in 9.2 when maybe it should not