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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
