Re: out-of-order caution - Mailing list pgsql-hackers

From Tom Lane
Subject Re: out-of-order caution
Date
Msg-id 4266.1319743842@sss.pgh.pa.us
Whole thread Raw
In response to Re: out-of-order caution  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.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


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Next
From: Tom Lane
Date:
Subject: Re: out-of-order caution