[MDEV-4010] Deadlock on concurrent INSERT .. SELECT into an Aria table with statement binary logging - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.0.1, 5.5.28a, 5.3.11, 5.2.13, 5.1.66
Fix Version/s: 5.5.41, 10.0.16
Component/s: Storage Engine - Aria
Labels:
- Aria

Description

In the provided test scenario, 2 threads run INSERT .. SELECT on the same Aria table. Very soon after the test start processlist starts showing something like

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

| Id | User | Host            | db   | Command | Time | State                        | Info                                  | Progress |

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

|  4 | root | localhost:54206 | test | Query   |  112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 |    0.000 |

|  5 | root | localhost:54207 | test | Query   |  112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 |    0.000 |

|  8 | root | localhost:54210 | NULL | Query   |    0 | NULL                         | show processlist                      |    0.000 |

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

Killing one of the threads (or a query in a thread) does not unlock another one:

elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "kill 4"

elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "show processlist"

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

| Id | User | Host            | db   | Command | Time | State                        | Info                                  | Progress |

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

|  5 | root | localhost:54207 | test | Query   |  129 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 |    0.000 |

| 10 | root | localhost:54212 | NULL | Query   |    0 | NULL                         | show processlist                      |    0.000 |

+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+

Reproducible on debug and release builds.
Reproducible on MariaDB 5.1, 5.2, 5.3, 5.5, 10.0.
Reproducible on Windows, Linux 64-bit and Linux 32-bit.
Could not reproduce with MyISAM or InnoDB, hence could not check whether the problem exists in MySQL.
Could not reproduce without binary logging or with row-based binlog format.

------------
Later addition:

While looking into ~~MDEV-7314~~, I got an MTR test case:

--source include/have_binlog_format_statement.inc

create table t1 (pk int primary key) engine=Aria;

insert into t1 values (1);

send insert into t1 select sleep(2)+1 from t1;

--connect (con1,localhost,root,,)

insert into t1 select 2 from t1;

--connection default

--reap

------------

Initial test (RQG)

If on some reason you are not getting the deadlock right away, try to increase threads and/or duration in the command-line options below.

RQG grammar (put it in the root of randgen folder as test.yy):

query_init:

	SET binlog_format = STATEMENT ; DROP TABLE IF EXISTS A ; CREATE TABLE IF NOT EXISTS A (`i` INT) ENGINE=Aria ; INSERT INTO A VALUES (1),(2),(3);

query:

	INSERT INTO A SELECT * FROM A LIMIT 0;

The test flow above contains LIMIT 0 only to prevent the table from growing uncontrollably, if the deadlock doesn't happen right away. The clause is unimportant, the problem happens without it as well.

RQG command line to run on a previous started server, assuming it's running on port 3306 (if the port is different, modify dsn); don't forget to start server with log-bin, no other options are necessary:

perl gentest.pl --threads=2 --queries=100M --duration=60 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=test.yy

RQG command line to run full test (which starts servers, etc.); it will start server on port 19300:

perl ./runall.pl \

--threads=2 \

--duration=60 \

--queries=100M \

--grammar=test.yy \

--skip-gendata \

--rpl_mode=statement \

--basedir=<your basedir> \

--vardir=<your vardir>

Attachments

Issue Links

is duplicated by

MDEV-7314 Concurrent "INSERT INTO table SELECT MAX(id)+1 FROM table" are hitting deadlocks on Aria tables using ROW_FORMAT=PAGE

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2013-01-07 19:40

Elena Stepanova made changes - 2013-01-07 19:40

Field	Original Value	New Value
Link		This issue relates to TODO-60 [ TODO-60 ]

Elena Stepanova added a comment - 2013-01-07 19:42

For Monty:
that's the same deadlock you started looking at during max_query_time tests; it turned out to be unrelated to the feature.

Elena Stepanova added a comment - 2013-01-07 19:42 For Monty: that's the same deadlock you started looking at during max_query_time tests; it turned out to be unrelated to the feature.

Sergei Golubchik made changes - 2013-03-11 22:25

Fix Version/s		5.5.31 [ 12700 ]
Fix Version/s	5.5.30 [ 11800 ]

Sergei Golubchik made changes - 2013-04-28 16:58

Fix Version/s		10.0.3 [ 12900 ]
Fix Version/s	10.0.2 [ 11900 ]

Sergei Golubchik made changes - 2013-05-24 12:55

Fix Version/s		5.5.32 [ 13000 ]
Fix Version/s	5.5.31 [ 12700 ]

Sergei Golubchik made changes - 2013-06-04 15:39

Fix Version/s		10.0.4 [ 13101 ]
Fix Version/s	10.0.3 [ 12900 ]

Sergei Golubchik made changes - 2013-07-18 19:39

Fix Version/s		5.5.33 [ 13300 ]
Fix Version/s	5.5.32 [ 13000 ]

Sergei Golubchik made changes - 2013-08-16 16:27

Fix Version/s		10.0.5 [ 13201 ]
Fix Version/s	10.0.4 [ 13101 ]

Sergei Golubchik made changes - 2013-09-16 19:04

Fix Version/s		5.5.34 [ 13500 ]
Fix Version/s	5.5.33 [ 13300 ]

Sergei Golubchik made changes - 2013-09-20 18:22

Fix Version/s		5.5.34 [ 13700 ]
Fix Version/s	5.5.33a [ 13500 ]

Sergei Golubchik made changes - 2013-11-05 23:01

Fix Version/s		10.0.6 [ 13202 ]
Fix Version/s	10.0.5 [ 13201 ]

Sergei Golubchik made changes - 2013-11-18 21:52

Fix Version/s		10.0.7 [ 14100 ]
Fix Version/s	10.0.6 [ 13202 ]

Sergei Golubchik made changes - 2013-11-21 21:02

Fix Version/s		5.5.35 [ 14000 ]
Fix Version/s	5.5.34 [ 13700 ]

Sergei Golubchik made changes - 2013-12-28 17:50

Fix Version/s		10.0.8 [ 14200 ]
Fix Version/s	10.0.7 [ 14100 ]

Sergei Golubchik made changes - 2014-01-29 10:10

Fix Version/s		5.5.36 [ 14600 ]
Fix Version/s	5.5.35 [ 14000 ]

Sergei Golubchik made changes - 2014-02-10 16:13

Fix Version/s		10.0.9 [ 14400 ]
Fix Version/s	10.0.8 [ 14200 ]

Sergei Golubchik made changes - 2014-02-24 21:51

Fix Version/s		5.5.37 [ 15000 ]
Fix Version/s	5.5.36 [ 14600 ]

Sergei Golubchik made changes - 2014-03-09 22:02

Fix Version/s		10.0.10 [ 14500 ]
Fix Version/s	10.0.9 [ 14400 ]

Sergei Golubchik made changes - 2014-03-31 14:23

Fix Version/s		10.0.11 [ 15200 ]
Fix Version/s	10.0.10 [ 14500 ]

Sergei Golubchik made changes - 2014-04-15 23:53

Fix Version/s		5.5.38 [ 15400 ]
Fix Version/s	5.5.37 [ 15000 ]

Sergei Golubchik made changes - 2014-05-10 23:13

Fix Version/s		10.0.12 [ 15201 ]
Fix Version/s	10.0.11 [ 15200 ]

Sergei Golubchik made changes - 2014-06-06 10:26

Fix Version/s		5.5.39 [ 15800 ]
Fix Version/s	5.5.38 [ 15400 ]

Sergei Golubchik made changes - 2014-06-13 15:06

Workflow

defaullt [ 25784 ]

MariaDB v2 [ 45009 ]

Sergei Golubchik made changes - 2014-06-16 13:27

Fix Version/s		10.0.13 [ 16000 ]
Fix Version/s	10.0.12 [ 15201 ]

Elena Stepanova added a comment - 2014-12-14 01:55

Increased the priority since we've got an external bug report about the same problem, see ~~MDEV-7314~~. It also contains a different test case, php, which might be easier to use or at least a good alternative in case the RQG one does not cause the deadlock.

Elena Stepanova added a comment - 2014-12-14 01:55 Increased the priority since we've got an external bug report about the same problem, see MDEV-7314 . It also contains a different test case, php, which might be easier to use or at least a good alternative in case the RQG one does not cause the deadlock.

Elena Stepanova made changes - 2014-12-14 01:55

Link

This issue is duplicated by ~~MDEV-7314~~ [ ~~MDEV-7314~~ ]

Elena Stepanova made changes - 2014-12-14 01:55

Priority

Minor [ 4 ]

Major [ 3 ]

Elena Stepanova made changes - 2014-12-14 16:08

Description

In the provided test scenario, 2 threads run INSERT .. SELECT on the same Aria table. Very soon after the test start processlist starts showing something like

{noformat}
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 4 | root | localhost:54206 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 5 | root | localhost:54207 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 8 | root | localhost:54210 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Killing one of the threads (or a query in a thread) does not unlock another one:

{noformat}
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "kill 4"
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "show processlist"
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 5 | root | localhost:54207 | test | Query | 129 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 10 | root | localhost:54212 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Reproducible on debug and release builds.
Reproducible on MariaDB 5.1, 5.2, 5.3, 5.5, 10.0.
Reproducible on Windows, Linux 64-bit and Linux 32-bit.
Could not reproduce with MyISAM or InnoDB, hence could not check whether the problem exists in MySQL.
Could not reproduce without binary logging or with row-based binlog format.

If on some reason you are not getting the deadlock right away, try to increase {{threads}} and/or {{duration}} in the command-line options below.

RQG grammar (put it in the root of randgen folder as {{test.yy}}):
{noformat}
query_init:
SET binlog_format = STATEMENT ; DROP TABLE IF EXISTS A ; CREATE TABLE IF NOT EXISTS A (`i` INT) ENGINE=Aria ; INSERT INTO A VALUES (1),(2),(3);

query:
INSERT INTO A SELECT * FROM A LIMIT 0;
{noformat}

The test flow above contains {{LIMIT 0}} only to prevent the table from growing uncontrollably, if the deadlock doesn't happen right away. The clause is unimportant, the problem happens without it as well.

RQG command line to run on a previous started server, assuming it's running on port 3306 (if the port is different, modify dsn); don't forget to start server with {{log-bin}}, no other options are necessary:
{noformat}
perl gentest.pl --threads=2 --queries=100M --duration=60 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=test.yy
{noformat}

RQG command line to run full test (which starts servers, etc.); it will start server on port 19300:
{noformat}
perl ./runall.pl \
--threads=2 \
--duration=60 \
--queries=100M \
--grammar=test.yy \
--skip-gendata \
--rpl_mode=statement \
--basedir=<your basedir> \
--vardir=<your vardir>
{noformat}

In the provided test scenario, 2 threads run INSERT .. SELECT on the same Aria table. Very soon after the test start processlist starts showing something like

{noformat}
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 4 | root | localhost:54206 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 5 | root | localhost:54207 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 8 | root | localhost:54210 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Killing one of the threads (or a query in a thread) does not unlock another one:

{noformat}
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "kill 4"
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "show processlist"
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 5 | root | localhost:54207 | test | Query | 129 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 10 | root | localhost:54212 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Reproducible on debug and release builds.
Reproducible on MariaDB 5.1, 5.2, 5.3, 5.5, 10.0.
Reproducible on Windows, Linux 64-bit and Linux 32-bit.
Could not reproduce with MyISAM or InnoDB, hence could not check whether the problem exists in MySQL.
Could not reproduce without binary logging or with row-based binlog format.

------------
*Later addition*:

While looking into ~~MDEV-7314~~, I got an MTR test case:
{code:sql}
--source include/have_binlog_format_statement.inc

create table t1 (pk int primary key) engine=Aria;
insert into t1 values (1);

send insert into t1 select sleep(2)+1 from t1;

--connect (con1,localhost,root,,)

insert into t1 select 2 from t1;

--connection default
--reap
{code}

------------

If on some reason you are not getting the deadlock right away, try to increase {{threads}} and/or {{duration}} in the command-line options below.

RQG grammar (put it in the root of randgen folder as {{test.yy}}):
{noformat}
query_init:
SET binlog_format = STATEMENT ; DROP TABLE IF EXISTS A ; CREATE TABLE IF NOT EXISTS A (`i` INT) ENGINE=Aria ; INSERT INTO A VALUES (1),(2),(3);

query:
INSERT INTO A SELECT * FROM A LIMIT 0;
{noformat}

The test flow above contains {{LIMIT 0}} only to prevent the table from growing uncontrollably, if the deadlock doesn't happen right away. The clause is unimportant, the problem happens without it as well.

RQG command line to run on a previous started server, assuming it's running on port 3306 (if the port is different, modify dsn); don't forget to start server with {{log-bin}}, no other options are necessary:
{noformat}
perl gentest.pl --threads=2 --queries=100M --duration=60 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=test.yy
{noformat}

RQG command line to run full test (which starts servers, etc.); it will start server on port 19300:
{noformat}
perl ./runall.pl \
--threads=2 \
--duration=60 \
--queries=100M \
--grammar=test.yy \
--skip-gendata \
--rpl_mode=statement \
--basedir=<your basedir> \
--vardir=<your vardir>
{noformat}

Elena Stepanova made changes - 2014-12-14 16:09

Description

In the provided test scenario, 2 threads run INSERT .. SELECT on the same Aria table. Very soon after the test start processlist starts showing something like

{noformat}
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 4 | root | localhost:54206 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 5 | root | localhost:54207 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 8 | root | localhost:54210 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Killing one of the threads (or a query in a thread) does not unlock another one:

{noformat}
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "kill 4"
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "show processlist"
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 5 | root | localhost:54207 | test | Query | 129 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 10 | root | localhost:54212 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Reproducible on debug and release builds.
Reproducible on MariaDB 5.1, 5.2, 5.3, 5.5, 10.0.
Reproducible on Windows, Linux 64-bit and Linux 32-bit.
Could not reproduce with MyISAM or InnoDB, hence could not check whether the problem exists in MySQL.
Could not reproduce without binary logging or with row-based binlog format.

------------
*Later addition*:

While looking into ~~MDEV-7314~~, I got an MTR test case:
{code:sql}
--source include/have_binlog_format_statement.inc

create table t1 (pk int primary key) engine=Aria;
insert into t1 values (1);

send insert into t1 select sleep(2)+1 from t1;

--connect (con1,localhost,root,,)

insert into t1 select 2 from t1;

--connection default
--reap
{code}

------------

If on some reason you are not getting the deadlock right away, try to increase {{threads}} and/or {{duration}} in the command-line options below.

RQG grammar (put it in the root of randgen folder as {{test.yy}}):
{noformat}
query_init:
SET binlog_format = STATEMENT ; DROP TABLE IF EXISTS A ; CREATE TABLE IF NOT EXISTS A (`i` INT) ENGINE=Aria ; INSERT INTO A VALUES (1),(2),(3);

query:
INSERT INTO A SELECT * FROM A LIMIT 0;
{noformat}

The test flow above contains {{LIMIT 0}} only to prevent the table from growing uncontrollably, if the deadlock doesn't happen right away. The clause is unimportant, the problem happens without it as well.

RQG command line to run on a previous started server, assuming it's running on port 3306 (if the port is different, modify dsn); don't forget to start server with {{log-bin}}, no other options are necessary:
{noformat}
perl gentest.pl --threads=2 --queries=100M --duration=60 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=test.yy
{noformat}

RQG command line to run full test (which starts servers, etc.); it will start server on port 19300:
{noformat}
perl ./runall.pl \
--threads=2 \
--duration=60 \
--queries=100M \
--grammar=test.yy \
--skip-gendata \
--rpl_mode=statement \
--basedir=<your basedir> \
--vardir=<your vardir>
{noformat}

In the provided test scenario, 2 threads run INSERT .. SELECT on the same Aria table. Very soon after the test start processlist starts showing something like

{noformat}
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 4 | root | localhost:54206 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 5 | root | localhost:54207 | test | Query | 112 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 8 | root | localhost:54210 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Killing one of the threads (or a query in a thread) does not unlock another one:

{noformat}
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "kill 4"
elenst@ubuntu11:~/5.5.28-release$ mysql -uroot --protocol=tcp --port=3306 -e "show processlist"
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
| 5 | root | localhost:54207 | test | Query | 129 | Waiting for table level lock | INSERT INTO A SELECT * FROM A LIMIT 0 | 0.000 |
| 10 | root | localhost:54212 | NULL | Query | 0 | NULL | show processlist | 0.000 |
+----+------+-----------------+------+---------+------+------------------------------+---------------------------------------+----------+
{noformat}

Reproducible on debug and release builds.
Reproducible on MariaDB 5.1, 5.2, 5.3, 5.5, 10.0.
Reproducible on Windows, Linux 64-bit and Linux 32-bit.
Could not reproduce with MyISAM or InnoDB, hence could not check whether the problem exists in MySQL.
Could not reproduce without binary logging or with row-based binlog format.

------------
*Later addition*:

While looking into ~~MDEV-7314~~, I got an MTR test case:
{code:sql}
--source include/have_binlog_format_statement.inc

create table t1 (pk int primary key) engine=Aria;
insert into t1 values (1);

send insert into t1 select sleep(2)+1 from t1;

--connect (con1,localhost,root,,)

insert into t1 select 2 from t1;

--connection default
--reap
{code}

------------

*Initial test (RQG)*

If on some reason you are not getting the deadlock right away, try to increase {{threads}} and/or {{duration}} in the command-line options below.

RQG grammar (put it in the root of randgen folder as {{test.yy}}):
{noformat}
query_init:
SET binlog_format = STATEMENT ; DROP TABLE IF EXISTS A ; CREATE TABLE IF NOT EXISTS A (`i` INT) ENGINE=Aria ; INSERT INTO A VALUES (1),(2),(3);

query:
INSERT INTO A SELECT * FROM A LIMIT 0;
{noformat}

The test flow above contains {{LIMIT 0}} only to prevent the table from growing uncontrollably, if the deadlock doesn't happen right away. The clause is unimportant, the problem happens without it as well.

RQG command line to run on a previous started server, assuming it's running on port 3306 (if the port is different, modify dsn); don't forget to start server with {{log-bin}}, no other options are necessary:
{noformat}
perl gentest.pl --threads=2 --queries=100M --duration=60 --dsn=dbi:mysql:host=127.0.0.1:port=3306:user=root:database=test --grammar=test.yy
{noformat}

RQG command line to run full test (which starts servers, etc.); it will start server on port 19300:
{noformat}
perl ./runall.pl \
--threads=2 \
--duration=60 \
--queries=100M \
--grammar=test.yy \
--skip-gendata \
--rpl_mode=statement \
--basedir=<your basedir> \
--vardir=<your vardir>
{noformat}

Michael Widenius made changes - 2014-12-15 13:06

Status

Open [ 1 ]

In Progress [ 3 ]

Michael Widenius made changes - 2014-12-15 14:51

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Michael Widenius added a comment - 2014-12-15 14:53

There was a bug in lock handling when mixing INSERT ... SELECT on the same table.
Fix pushed into 5.5 tree

Michael Widenius added a comment - 2014-12-15 14:53 There was a bug in lock handling when mixing INSERT ... SELECT on the same table. Fix pushed into 5.5 tree

Michael Widenius made changes - 2014-12-15 14:53

Component/s		Storage Engine - Aria [ 10126 ]
Fix Version/s		10.0.16 [ 17900 ]
Fix Version/s		5.5.41 [ 17600 ]
Fix Version/s	5.5 [ 15800 ]
Fix Version/s	10.0 [ 16000 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:51

Workflow

MariaDB v2 [ 45009 ]

MariaDB v3 [ 65529 ]

Sergei Golubchik made changes - 2021-12-06 21:38

Workflow

MariaDB v3 [ 65529 ]

MariaDB v4 [ 146314 ]

People

Assignee:: Michael Widenius

Reporter:: Elena Stepanova

Votes:: 1 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2013-01-07 19:40

Updated:: 2014-12-15 14:53

Resolved:: 2014-12-15 14:53

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration