Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.30
-
None
Description
Initially reported on the sales list. Quoting the complete text of the report from the mail, additional information follows the quote:
System: Windows 32 and 64 bit (tested on XP/32, 2003/32 and 2008/64)
Effected: MariaDB up to 5.5.30I have a specific (attached) Aria table with 2 columns, the fist being indexed as non-unique.
CREATE TABLE `test` (
`id` SMALLINT(5) UNSIGNED NOT NULL,
`kundenid` SMALLINT(5) UNSIGNED NOT NULL,
INDEX `id` (`id`)
)
ENGINE=Aria;In this table there are 42 records, 13 of them having id=4. When I add 2 more with id 4 and query all entries with id=4, it only shows me the 13 that already were in the database, but not the 2 newly added. They are only shown when I query all records.
How to reproduce:
1) Install a fresh copy of MariaDB (5.5.30)
2) Copy attached my.ini in the appropriate folder and
3) the test.* files in the test database.
4) Run following queries:SELECT * FROM test;
/* Affected rows: 0 Found rows: 42 Warnings: 0 Duration for 1 query: 0,000 sec. */SELECT * FROM test WHERE id=4;
/* Affected rows: 0 Found rows: 13 Warnings: 0 Duration for 1 query: 0,000 sec. */INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345);
INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 24587);
/* Affected rows: 2 Found rows: 0 Warnings: 0 Duration for 2 queries: 0,016 sec. */SELECT * FROM test;
/* Affected rows: 0 Found rows: 44 Warnings: 0 Duration for 1 query: 0,000 sec. */SELECT * FROM test WHERE id=4;
/* Affected rows: 0 Found rows: 13 Warnings: 0 Duration for 1 query: 0,000 sec. */Only
REPAIR TABLE `test`;
recovers the missing records when selecting WHERE id=4:REPAIR TABLE `test`;
/* Affected rows: 0 Found rows: 1 Warnings: 0 Duration for 1 query: 0,062 sec. */
SELECT * FROM test WHERE id=4;
/* Affected rows: 0 Found rows: 15 Warnings: 0 Duration for 1 query: 0,000 sec. */
Additional information
The issue is reproducible on Linux as well, even without the my.ini file. The problems start with the first INSERT. On a release build, it causes the table corruption, on the debug build it causes assertion failure.
On a debug build:
mysqld: 5.5/storage/maria/ma_key.c:103: transid_store_packed: Assertion `trid >= info->s->state.create_trid' failed.
|
[ERROR] mysqld got signal 6 ;
|
#7 0x00007fd94ec0a192 in __GI___assert_fail (assertion=0xe0fed8 "trid >= info->s->state.create_trid", file=0xe0fe90 "5.5/storage/maria/ma_key.c", line=103, function=0xe0fff0 "transid_store_packed") at assert.c:103
|
#8 0x00000000009b3cf9 in transid_store_packed (info=0x7fd904013490, to=0x7fd904017bbb "\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245", trid=44) at 5.5/storage/maria/ma_key.c:103
|
#9 0x00000000009b46a1 in _ma_make_key (info=0x7fd904013490, int_key=0x7fd9503cd8e0, keynr=0, key=0x7fd904017bb7 "", record=0x7fd904008e68 "\377\004", filepos=298, trid=44) at 5.5/storage/maria/ma_key.c:326
|
#10 0x00000000009d62ba in maria_write (info=0x7fd904013490, record=0x7fd904008e68 "\377\004") at 5.5/storage/maria/ma_write.c:188
|
#11 0x000000000095c805 in ha_maria::write_row (this=0x7fd90400c6d8, buf=0x7fd904008e68 "\377\004") at 5.5/storage/maria/ha_maria.cc:1265
|
#12 0x00000000007d06c9 in handler::ha_write_row (this=0x7fd90400c6d8, buf=0x7fd904008e68 "\377\004") at 5.5/sql/handler.cc:5162
|
#13 0x00000000005f57a7 in write_record (thd=0x3f60bd0, table=0x7fd90400bd10, info=0x7fd9503cdb50) at 5.5/sql/sql_insert.cc:1850
|
#14 0x00000000005f33fc in mysql_insert (thd=0x3f60bd0, table_list=0x7fd904006628, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at 5.5/sql/sql_insert.cc:995
|
#15 0x0000000000611d4e in mysql_execute_command (thd=0x3f60bd0) at 5.5/sql/sql_parse.cc:2935
|
#16 0x0000000000619df6 in mysql_parse (thd=0x3f60bd0, rawbuf=0x7fd904006508 "INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345)", length=55, parser_state=0x7fd9503ce550) at 5.5/sql/sql_parse.cc:5756
|
#17 0x000000000060d598 in dispatch_command (command=COM_QUERY, thd=0x3f60bd0, packet=0x404fd11 "INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345)", packet_length=55) at 5.5/sql/sql_parse.cc:1068
|
#18 0x000000000060c7dd in do_command (thd=0x3f60bd0) at 5.5/sql/sql_parse.cc:794
|
#19 0x0000000000710e36 in do_handle_one_connection (thd_arg=0x3f60bd0) at 5.5/sql/sql_connect.cc:1266
|
#20 0x0000000000710821 in handle_one_connection (arg=0x3f60bd0) at 5.5/sql/sql_connect.cc:1181
|
#21 0x00007fd94f9dae9a in start_thread (arg=0x7fd9503cf700) at pthread_create.c:308
|
The stack trace from
revision-id: sanja@askmonty.org-20130314170720-7qhmgzam5831ak30
|
revno: 3699
|
On a release build:
MariaDB [test]> check table test extended; |
+-----------+-------+----------+----------+age done |
| Table | Op | Msg_type | Msg_text | |
+-----------+-------+----------+----------+ |
| test.test | check | status | OK | |
+-----------+-------+----------+----------+ |
1 row in set (0.12 sec) |
|
|
MariaDB [test]> show index in test; |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ |
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ |
| test | 1 | id | 1 | id | A | 5 | NULL | NULL | | BTREE | | | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ |
1 row in set (0.00 sec) |
|
|
MariaDB [test]> select count(*) from test; |
+----------+ |
| count(*) | |
+----------+ |
| 42 |
|
+----------+ |
1 row in set (0.06 sec) |
|
|
MariaDB [test]> show table status like 'test'; |
+------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+ |
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | |
+------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+ |
| test | Aria | 10 | Page | 42 | 390 | 16384 | 68719484928 | 16384 | 0 | NULL | 2013-01-07 16:46:42 | 2013-03-18 01:38:11 | 2013-03-18 01:38:51 | utf8_general_ci | NULL | page_checksum=1 | Loginrechte für die Nielsen-Statistik | |
+------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+ |
1 row in set (0.05 sec) |
|
|
MariaDB [test]> INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345); |
Query OK, 1 row affected (0.05 sec)
|
|
|
MariaDB [test]> check table test extended; |
+-----------+-------+----------+---------------------------------------------------------------+ |
| Table | Op | Msg_type | Msg_text | |
+-----------+-------+----------+---------------------------------------------------------------+ |
| test.test | check | error | Found key at page 8192 that points to record outside datafile | |
| test.test | check | error | Corrupt | |
+-----------+-------+----------+---------------------------------------------------------------+ |
2 rows in set (0.05 sec) |
However, I couldn't reproduce the problem by dumping the table and restoring the dump. I could try more if I get any hint on what can possibly cause this. Meanwhile I asked the reporter by email for more information on how they got the table in this state, haven't got a response yet.