Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.postgresql > #113
| From | Jasen Betts <jasen@xnet.co.nz> |
|---|---|
| Newsgroups | comp.databases.postgresql |
| Subject | Re: Deadlock on the same select for update |
| Date | 2011-05-03 08:31 +0000 |
| Organization | Dis (not Dat) Organisation |
| Message-ID | <ipoeh3$4l4$1@reversiblemaps.ath.cx> (permalink) |
| References | <f7c3a742-d9c8-4e38-9708-a9f458a36a59@i14g2000yqe.googlegroups.com> <wZq*U2kwt@news.chiark.greenend.org.uk> <pan.2011.02.23.14.34.04@gmail.com> <zUj*3xvwt@news.chiark.greenend.org.uk> <1304409229.248884@proxy.dienste.wien.at> |
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 ---
Back to comp.databases.postgresql | Previous | Next — Previous in thread | Find similar
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
csiph-web