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
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 |