>>> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Kevin Grittner wrote:
>> (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.
My only point was that other DBMSs often generate serialization
failures on SELECT-only transactions in READ COMMITTED mode.
Sometimes quite a few of them. I also recognized that if PostgreSQL
can provide guarantees not required by the standard that such things
won't happen, I can see the value of that.
>> 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.
Well, for transactions which only SELECT, sure. Is there no use case
for them outside of that? (That's not rhetorical -- I'm not really
sure.)
-Kevin