Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.databases.postgresql > #109 > unrolled thread

Re: Deadlock on the same select for update

Started by"Laurenz Albe" <invite@spam.to.invalid>
First post2011-05-03 09:53 +0200
Last post2011-05-03 08:31 +0000
Articles 2 — 2 participants

Back to article view | Back to comp.databases.postgresql

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Deadlock on the same select for update "Laurenz Albe" <invite@spam.to.invalid> - 2011-05-03 09:53 +0200
    Re: Deadlock on the same select for update Jasen Betts <jasen@xnet.co.nz> - 2011-05-03 08:31 +0000

#109 — Re: Deadlock on the same select for update

From"Laurenz Albe" <invite@spam.to.invalid>
Date2011-05-03 09:53 +0200
SubjectRe: Deadlock on the same select for update
Message-ID<1304409229.248884@proxy.dienste.wien.at>
Matthew Woodcraft wrote:
> What I don't see a firm guarantee for is that ORDER BY on a SELECT FOR
> UPDATE controls the order in which the locks are taken, as opposed to
> just controlling the order of the result rows.

There's nothing in the documentation, but read Tom Lane's commit message
for a change introduced in 9.0:

http://archives.postgresql.org/pgsql-committers/2009-10/msg00127.php

  Instead, keep the present semantics of applying
  FOR UPDATE after ORDER BY within a single query level; but allow the user to
  specify the other way by writing FOR UPDATE in a sub-select.

So the locks will be taken in the order specified in ORDER BY in a
simple query, but
a) that is not a documented feature and
b) the commit message suggests that that is not written in stone.

So I wouldn't rely on it.

Yours,
Laurenz Albe 

[toc] | [next] | [standalone]


#113

FromJasen Betts <jasen@xnet.co.nz>
Date2011-05-03 08:31 +0000
Message-ID<ipoeh3$4l4$1@reversiblemaps.ath.cx>
In reply to#109
On 2011-05-03, Laurenz Albe <invite@spam.to.invalid> wrote:
> Matthew Woodcraft wrote:
>> What I don't see a firm guarantee for is that ORDER BY on a SELECT FOR
>> UPDATE controls the order in which the locks are taken, as opposed to
>> just controlling the order of the result rows.
>
>
> So the locks will be taken in the order specified in ORDER BY in a
> simple query, but
> a) that is not a documented feature and
> b) the commit message suggests that that is not written in stone.

IIRC Tom's comment at the time was that, this behaviour would continue
until something better was developed. 

-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [standalone]


Back to top | Article view | comp.databases.postgresql


csiph-web