Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.postgresql > #109 > unrolled thread
| Started by | "Laurenz Albe" <invite@spam.to.invalid> |
|---|---|
| First post | 2011-05-03 09:53 +0200 |
| Last post | 2011-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.
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
| From | "Laurenz Albe" <invite@spam.to.invalid> |
|---|---|
| Date | 2011-05-03 09:53 +0200 |
| Subject | Re: 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]
| From | Jasen Betts <jasen@xnet.co.nz> |
|---|---|
| Date | 2011-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