Re: Actual row order in UPDATE and SELECT FOR UPDATE

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Nikolai Zhubr <n-a-zhubr(at)yandex(dot)ru>, pgsql-general(at)postgresql(dot)org
Subject: Re: Actual row order in UPDATE and SELECT FOR UPDATE
Date: 2016-02-15 22:27:09
Message-ID: 56C250BD.3090300@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 02/15/2016 02:17 PM, Nikolai Zhubr wrote:
> Hello all,
>
> I can't find any clear description of how to reliably figure and/or
> enforce specific row (locking) order within UPDATE and SELECT FOR UPDATE
> statements dealing with multiple rows.
> I'd like to get rid of some deadlocks (caused by share locks). While the
> manual explains locks and deadlocks themselves pretty fine (in e.g.
> http://www.postgresql.org/docs/9.5/static/explicit-locking.html
> ) it somehow avoids discussing multi-row updates there. On the other
> hand, the UPDATE section of the manual somehow avoids discussing actual
> update order and respective locking too.
> So is it defined anywhere explicitely? Or do I rather have to convert
> all multi-row UPDATE statements into single-row updates and then wrap
> them into e.g. plpgsql loops? That would look quite strange...
> Any hints?

http://www.postgresql.org/docs/9.4/interactive/transaction-iso.html

Might also help if you give a code example of what you are trying to do?

>
>
> Thank you,
> Nikolai
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2016-02-15 23:20:10 Re: Actual row order in UPDATE and SELECT FOR UPDATE
Previous Message Nikolai Zhubr 2016-02-15 22:17:52 Actual row order in UPDATE and SELECT FOR UPDATE