Kevin Grittner wrote:
> Well, that's a PostgreSQL-specific point of view, although I
> understand the point of maintaining that guarantee. (In Microsoft SQL
> Server and Sybase ASE we actually had to run our read-only web
> application at the READ UNCOMMITTED transaction isolation level
> because so many SELECT queries were rolled back when they deadlocked
> with the traffic from replication when they were all running at READ
> COMMITTED.)
Per SQL standard, READ UNCOMMITTED mode requires READ ONLY transaction
access mode, so you couldn't do FOR UPDATE there anyway. (Of course,
FOR UPDATE is not in the standard.)
> If you run this at SERIALIZABLE transaction isolation level, would
> PostgreSQL currently roll something back before returning rows in an
> order different than that specified by the ORDER BY clause?
Yes, but using FOR UPDATE is kind of pointless in serializable mode.
