Re: out-of-order caution

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
>> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>> | It is possible for a SELECT command using ORDER BY and FOR
>>> | UPDATE/SHARE to return rows out of order. This is because ORDER
>>> | BY is applied first.

>> I think it should say that if this occurs with SERIALIZED
>> transactions it will result in a serialisation error.

> Hmm. At first reading I thought this was related to the
> mixed-snapshot issue in READ COMMITTED, but now I'm not so sure.

Simon's comment is correct. If you do a SELECT FOR UPDATE/SHARE in a
non-READ-COMMITTED transaction, and it turns out that someone modified
the tuple before you could lock it, you'll get a serialization error
(cf ExecLockRows()), not updated data. So out-of-order sorting is
not possible.

regards, tom lane