MySQL Bugs: #37988: Test "xml" is not protected against existing table

Bug #37988	Test "xml" is not protected against existing table
Submitted:	9 Jul 2008 11:54	Modified:	3 Oct 2008 7:47
Reporter:	Joerg Bruehe	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S3 (Non-critical)
Version:	5.1.26-rc	OS:	Windows
Assigned to:	Ramil Kalimullin	CPU Architecture:	Any

Description:
Test "xml" fails in the 5.1.26-rc build,
but it happened only in the "classic" build on Windows-64.

I suspect this is because some preceding test was skipped there (or failed), so "xml" found the database in a different state than in other runs:

=====
main.xml                       [ fail ]

mysqltest: At line NNN: query 'CREATE TABLE t1(a INT NOT NULL)' failed: 1050: Table 't1' already exists

The result from queries just before the failure was:
...
select updatexml(NULL, NULL, NULL);
updatexml(NULL, NULL, NULL)
NULL
CREATE TABLE t1(a INT NOT NULL);

More results from queries before failure can be found in /PATH/mysql-test/var/log/xml.log
=====

How to repeat:
Run the test suite in this configuration.

Suggested fix:
Add a "DROP TABLE IF EXISTS ..."

Error in the original text:

It happens in "classic" builds on both Windows platforms, 32 or 64 bit.
Sorry !

The way our test suite works is that each test is supposed to clean up for itself. So the problem is someplace else. Please report the reason for this.

You are not telling me an arbitrary test may be programmed such that it depends on the preceding tests having finished (= not crashed), are you?
That would be an optimistic assumption, and so is unusable.

Consider for example test "alias": It starts
  --disable_warnings
  DROP TABLE IF EXISTS t1;
  --enable_warnings
  CREATE TABLE t1 (
So regardless of the current database contents, table "t1" can be created.

Now look at test "xml":
The first occurrence of "t1" is in a "create table" statement, this will obviously fail if the table exists (this bug).

It simply lacks a "drop table if exists".

Accepted as "Not a bug",
the QA consensus is that the preceding test should have cleaned up
(or, if crashed, that the test script should have restored a clean DB).

I will have to search the preceding test which left the table around.