From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: out-of-order caution |
Date: | 2011-10-27 19:30:42 |
Message-ID: | 4266.1319743842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-27 19:40:22 | Re: out-of-order caution |
Previous Message | Florian Pflug | 2011-10-27 19:23:16 | Re: Hot Backup with rsync fails at pg_clog if under load |