Bug #36134 Random failures of backup_tablespace test
Submitted: 16 Apr 2008 11:37 Modified: 21 May 2008 15:12
Reporter: Rafal Somla Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: CPU Architecture:Any

[16 Apr 2008 11:37] Rafal Somla
Sometimes, backup_tablespace fails with error

> mysqltest: At line 27: query 'CREATE TABLE backup_ts.not_ts (id int, comment 
> char(40)) ENGINE=FALCON' failed: 1005: Can't create table 'backup_ts.not_ts' 
> (errno: 156)

This happens at the very beginning of the test, when objects on which test operates are created. More precisely, the following is executed before error happens:

--error 0,1
--remove_file $MYSQLTEST_VARDIR/master-data/backup_ts.bak;

CREATE TABLESPACE bup_ts ADD DATAFILE 'bup_ts.dat' COMMENT = 'test tablespace backup' ENGINE=FALCON;
CREATE TABLE backup_ts.not_ts (id int, comment char(40)) ENGINE=FALCON;

Thus the problem happens before any BACKUP or RESTORE statement are executes and is most probably internal to Falcon storeage egnie.

Note: perror says "MySQL error code 156: The table already existed in storage engine"

How to repeat:
Could not repeat it by running the test manually several times. 

Suggested fix:
One theory is that when DROP DATABASE backup_ts statement is executed, somehow tables stored by Falcon are not removed immediately. This is why later CREATE TABLE triggers the error.

A workaround could be to explicitly DROP all tables in backup_ts, before dropping the database.
[16 Apr 2008 12:14] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:


ChangeSet@1.2615, 2008-04-16 14:12:03+02:00, rafal@quant.(none) +1 -0
  BUG#36134 (Random failures of backup_tablespace test)
  The failure could be caused by DROP DATABASE backup_ts statmenet, executed at 
  the beginning of the test, not deleting all Falcon tables stored in it 
  This patch implements a workaround proposed in the bug report, that is, DROPS
  all tables explicitly.
[16 Apr 2008 12:17] Rafal Somla
The last patch is not a solution for this bug - it only implements the suggested workaround.
[16 Apr 2008 18:06] Bugs System
Pushed into 6.0.5-alpha
[21 May 2008 15:12] Philip Stoev
I abstraced the offending statements in a clean test case and ran it hundreds of times without a failure.

The consensus in the Falcon team is to close this bug.