Description:
When two threads execute the following queries, both will report affected_rows = 1 even though both queries should match two rows each:
Thread1:
UPDATE `table10_falcon_int`
SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10)
WHERE `pk` >= 0 ORDER BY `pk` ASC LIMIT 2
Thread2:
UPDATE `table10_falcon_int`
SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10)
WHERE `pk` >= 1 ORDER BY `pk` ASC LIMIT 2
Note that Thread1 attempts to update rows with PK 0 and 1 and Thread2 attempts to update rows with PK 1 and 2. Since the updates are ordered by PK, there is no reason for those queries to silently succeed with affected_rows = 1. Instead, both updates should have been successfull, or, at the very least, some transactional error should have been returned.
This test works fine under Innodb and non-concurrent Falcon. No errors are printed by the server.
How to repeat:
RQG ZZ file creates a table with 10 rows, each with a PK and a single integer key column:
$tables = { rows => [10] , pk => [ 'integer' ] };
$fields = { types => [ 'int' ], indexes => [ 'key' ] };
$data = { numbers => [ '100' ] }
RQG: YY file:
query:
UPDATE _table SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10) WHERE `pk` >= value ORDER BY `pk` ASC LIMIT 2 ;
value:
0 | 1;
To run:
$ perl runall.pl \
--basedir=/build/bzr/6.0-falcon-team/ \
--engine=Falcon \
--grammar=conf/transactions.yy \
--gendata=conf/transactions.zz
Soon after takeoff, the table will become inconsistent, e.g. the sum of the values in the integer key column will no longer be 1000.
Description: When two threads execute the following queries, both will report affected_rows = 1 even though both queries should match two rows each: Thread1: UPDATE `table10_falcon_int` SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10) WHERE `pk` >= 0 ORDER BY `pk` ASC LIMIT 2 Thread2: UPDATE `table10_falcon_int` SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10) WHERE `pk` >= 1 ORDER BY `pk` ASC LIMIT 2 Note that Thread1 attempts to update rows with PK 0 and 1 and Thread2 attempts to update rows with PK 1 and 2. Since the updates are ordered by PK, there is no reason for those queries to silently succeed with affected_rows = 1. Instead, both updates should have been successfull, or, at the very least, some transactional error should have been returned. This test works fine under Innodb and non-concurrent Falcon. No errors are printed by the server. How to repeat: RQG ZZ file creates a table with 10 rows, each with a PK and a single integer key column: $tables = { rows => [10] , pk => [ 'integer' ] }; $fields = { types => [ 'int' ], indexes => [ 'key' ] }; $data = { numbers => [ '100' ] } RQG: YY file: query: UPDATE _table SET `int_key` = `int_key` + IF(`pk` % 2 = 1 , 10, -10) WHERE `pk` >= value ORDER BY `pk` ASC LIMIT 2 ; value: 0 | 1; To run: $ perl runall.pl \ --basedir=/build/bzr/6.0-falcon-team/ \ --engine=Falcon \ --grammar=conf/transactions.yy \ --gendata=conf/transactions.zz Soon after takeoff, the table will become inconsistent, e.g. the sum of the values in the integer key column will no longer be 1000.