Chris Travers wrote on 06.01.2013 03:18:
i.e. where on UPDATE foo, all rows selected from foo during the
update are locked unless the subselect specifically states
otherwise.
That would strike *me* as wrong.
The UPDATE should only lock the rows that were actually updated, not those that
were
Hi everyone;
I recently discovered that subselects in update statements don't assume
that the select is for update of the updating table.
For example, if I do this:
CREATE TABLE foo (
test int primary key,
);
INSERT INTO foo VALUES (1);
then in one session:
BEGIN;
UPDATE foo SET test = 2
On Sunday, January 06, 2013 7:48 AM Chris Travers wrote:
I recently discovered that subselects in update statements don't assume that
the select is for update of the updating table.
For example, if I do this:
CREATE TABLE foo (
test int primary key,
);
INSERT INTO foo VALUES (1);
On Sunday, January 06, 2013 11:10 AM Amit kapila wrote:
On Sunday, January 06, 2013 7:48 AM Chris Travers wrote:
Is there a reason why we don't do locking this way? (i.e. where on UPDATE
foo, all rows selected from foo during the
update are locked unless the subselect specifically states
2013-01-06 03:18 keltezéssel, Chris Travers írta:
Hi everyone;
I recently discovered that subselects in update statements don't assume that the select
is for update of the updating table.
For example, if I do this:
CREATE TABLE foo (
test int primary key,
);
INSERT INTO foo VALUES (1);
