| Bug #24079 | strange errors around INSERT getting duplicate key, but one row is inserted | ||
|---|---|---|---|
| Submitted: | 8 Nov 2006 9:39 | Modified: | 7 Dec 2006 22:31 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
| Version: | 5.2 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[8 Nov 2006 10:00]
Matthias Leich
The testcase is falcon_bug_24079.
[10 Nov 2006 22:37]
Jim Starkey
Commits, rollbacks, and savesets operations were being applied to only the first storage connection for a thread.
[11 Nov 2006 0:40]
Hakan Küçükyılmaz
Test works now on Linux 64-bit, change set 1.2354, 2006-11-10. I had a successful run of falcon_bug_24079.test after setting if (0) to if (1) Regards, Hakan
[13 Nov 2006 19:13]
Matthias Leich
The problem within falcon_bug_24078 and also mix1_falcon (not yet pushed) is fixed. - mysql-5.1-falcon last ChangeSet@1.2359, 2006-11-12 - compile-pentium-debug-max - Intel Pentium M (x86-32Bit) - Linux (SuSE 10.1)
[29 Nov 2006 16:17]
Hakan Küçükyılmaz
Fails on Pushbuild because of --tmpdir setting. If --tmpdir contains a dash, falcon_bug_24079 fails: ./mysql-test-run.pl --timer --tmpdir=/tmp/tmp-n falcon_bug_24079 Logging: ./mysql-test-run.pl --timer --tmpdir=/tmp/tmp-n falcon_bug_24079 MySQL Version 5.1.13 Using binlog format 'mixed' Skipping ndbcluster, mysqld not compiled with ndbcluster Setting mysqld to support SSL connections Binaries are debug compiled Killing Possible Leftover Processes Removing Stale Files Installing Master Database Installing Master Database ======================================================= Starting Tests in the 'main' suite TEST RESULT TIME (ms) ------------------------------------------------------- falcon_bug_24079 [ fail ] Errors are (from /home/hakan/work/mysql/mysql-5.1-falcon/mysql-test/var/log/mysqltest-time) : mysqltest: At line 19: query 'CREATE TEMPORARY TABLE t3 ( f1 CHAR(10))' failed: 1005: Can't create table 'test.t3' (errno: 156) (the last lines may be the most important ones) Result from queries before failure can be found in r/falcon_bug_24079.log Note: If --tmpdir is set to /tmp, than the test works fine. For instance: ./mysql-test-run.pl --tmpdir=/dev/shm/tmp-a --skip-ndb falcon_bug_24079 will fail, while ./mysql-test-run.pl --tmpdir=/dev/shm/tmp --skip-ndb falcon_bug_24079 runs fine. Regards, Hakan
[5 Dec 2006 17:34]
Patrick Galbraith
See email on falcon_list/bk with heading: bk commit - 5.1-falcon tree (patg:1.2385) BUG#24079 ChangeSet@1.2385, 2006-12-05 12:15:52-05:00, patg@govinda.patg.net +5 -0 BUG #24079 Added arg tempTable to StorageConnection::getStorageTable and StorageTableShare::getTableShare. If table is a temp table, then we must just set the schema (internal schema in falcon tablespace file) to "TMP" because we cannot rely on the value passed to --tmpdir, which we have previously derived schemaName (used to build sql statement to create the table) from the pathname to be compliant to what falcon supports as a schemaName, so if it's a temp table, we simply say it will always be "TMP", which in the case of a temporary table, is stored in a falcon tablespace file ONLY used for temp tables, and will always be the same schemaName
[7 Dec 2006 22:31]
Hakan Küçükyılmaz
Runs fine now with Linux 32-bit change set 1.2354, 2006-12-07. ./mysql-test-run.pl --tmpdir=/dev/shm/tmp-a --skip-ndb falcon_bug_24079 TEST RESULT TIME (ms) ------------------------------------------------------- falcon_bug_24079 [ pass ] 1586 ------------------------------------------------------- Stopping All Servers All 1 tests were successful. The servers were restarted 1 times Spent 1.586 seconds actually executing testcases Regards, Hakan
Description: Simplified subtestcase derived from the not yet pushed test mix1_falcon ------------------------------------------------------ snip of my protocol: SET SESSION STORAGE_ENGINE = Falcon; CREATE TABLE t1 (a int, b int); insert into t1 values (1,2); CREATE TEMPORARY TABLE t3 ( f1 CHAR(10)); SELECT * FROM t3; f1 DROP TABLE t3; CREATE TABLE t2 (a int, b int, primary key (a)); SELECT * FROM t2; a b BEGIN; INSERT INTO t2 values(100,100); SELECT * FROM t2; a b 100 100 INSERT INTO t2 select 1,1 UNION ALL SELECT 1,1; ERROR 23000: Duplicate entry '1' for key 'PRIMARY' SELECT * from t2; a b 100 100 1 1 <--- This should never happen because ROLLBACK; Falcon is a transactional engine. DROP TABLE t1; DROP TABLE t2; ERROR 42S02: Unknown table 't2' <-- What's this ? ... CREATE TABLE t2 (a int, b int, primary key (a)); ERROR 42S01: Table 't2' already exists <--- Looks like something is really rotten. Note: 1. If I remove the "BEGIN" the bad effects around DROP TABLE t2 disappear, but not the bug around duplicate key. 2. The table cannot be dropped without previous shutdown and restart of the server. 3. Please look into the attached testcase. Simple modifications of the test before the problematic table is created can cause that the problem around duplicate key disappears. 4. We had a very similar bug in history https://intranet.mysql.com/~mmatthews/mantis/view.php?id=261 I set priority to P1 because the insertion of one record though the statement fails must never happen for a transactional storage engine. My environment: - PC Intel Pentium M (x86-32Bit) with Linux(SuSE 10.1) - MySQL compiled from source mysql-5.1-falcon last ChangeSet@1.2367, 2006-11-07 BUILD/compile-pentium-debug-max How to repeat: I will push a testcase just after bug report. The file with expected results refers to a test script where the "if (0)" is replaced with "if (1)".