On Fri, Oct 28, 2011 at 10:44 AM, Kevin Grittner
wrote:
> OK, doc patch attached.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
> wrote:
>> On the docs page for the SELECT statement, there is a caution
>> which starts with:
>>
>> | It is possible for a SELECT command using ORDER BY and FOR
>> | UPDATE/SHARE to return rows out of order. This is because OR
"Kevin Grittner" writes:
> (2) They *can* get a serialization failure involving just two
> transactions: a read and a write.
Only if you ignore the difference between SELECT FOR UPDATE/SHARE and
plain SELECT. I think calling the former a "read" is a conceptual error
to start with. It has the s
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
>> 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 t
Robert Haas wrote:
> Simple test case:
>
> rhaas=# create table oops (a int);
> CREATE TABLE
> rhaas=# insert into oops values (1), (2), (3), (4);
> INSERT 0 4
> rhaas=# begin;
> BEGIN
> rhaas=# update oops set a = 5 where a = 2;
> UPDATE 1
>
> In another session:
>
> rhaas=# select * from oops
On Thu, Oct 27, 2011 at 1:51 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
>> wrote:
>>> On the docs page for the SELECT statement, there is a caution
>>> which starts with:
>>>
>>> | It is possible for a SELECT command using ORDER BY and FOR
>
Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
> wrote:
>> On the docs page for the SELECT statement, there is a caution
>> which starts with:
>>
>> | It is possible for a SELECT command using ORDER BY and FOR
>> | UPDATE/SHARE to return rows out of order. This is because OR
On Thu, Oct 27, 2011 at 4:41 PM, Kevin Grittner
wrote:
> On the docs page for the SELECT statement, there is a caution which
> starts with:
>
> | 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.
On the docs page for the SELECT statement, there is a caution which
starts with:
| 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.
Is this risk limited to queries running in READ COMMITTED
transa
