292794 - Running checksetup.pl results in a cannot rename table error even though the table is verified in MySQL

Status: RESOLVED DUPLICATE of bug 307662

(Bugzilla :: Installation & Upgrading, defect)

Description

[Gary Penn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Running checksetup.pl I get the following error:
Name conflict: Cannot rename whine_schedules.mailto_userid to
whine_schedules.mailto, because whine_schedules.mailto already exists.

I have checked in MySQL and the column does not exist anywhere (though it did at
one point on an older sql database restore).  Is this cached somewhere or is it
a bug that once it's run with this error it never goes away?

Reproducible: Always

Steps to Reproduce:
1. Run ./checksetup.pl
2. Look in MySQL to confirm that the new column is not there
3.

Actual Results:  
whine_schedules.mailto does NOT exist.

Expected Results:  
whine_schedules.mailto should be created from whine_schedules.mailto_userid

Comment 1

[Gary Penn]

Additionally, here's the description of the table to prove the column is not
there as checksetup.pl claims it is:

mysql> desc whine_schedules;
+---------------+--------------+------+-----+---------+----------------+
| Field         | Type         | Null | Key | Default | Extra          |
+---------------+--------------+------+-----+---------+----------------+
| id            | mediumint(9) |      | PRI | NULL    | auto_increment |
| eventid       | mediumint(9) |      | MUL | 0       |                |
| run_day       | varchar(32)  | YES  |     | NULL    |                |
| run_time      | varchar(32)  | YES  |     | NULL    |                |
| run_next      | datetime     | YES  | MUL | NULL    |                |
| mailto_userid | mediumint(9) |      |     | 0       |                |
+---------------+--------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

mysql>

Comment 2

[Max Kanat-Alexander]

What version are you upgrading from, and what version are you upgrading to?

Comment 3

[Gary Penn]

From 2.19.2+ to 2.19.2+ (nightly updates).

Comment 4

[Max Kanat-Alexander]

I suspect that perhaps you restored only part of the database, at some point?

checksetup stores what it *thinks* the DB schema is in a table called bz_schema.
Every time it makes a modification to the schema, it stores that modification in
the bz_schema table. Whenever you restore the database, the exact bz_schema
table needs to be restored with it.

In this case, for a quick fix, you can probably just do:

"DELETE FROM bz_schema"

which will cause checksetup to re-read the DB schema.

However, I would like to know how you got into this situation, in case it
represents a bug in unreleased code.

Comment 5

[Zach Lipton [:zach]]

Gary -- Did you get this to work? It would be great to know how this ended up
happening.

Comment 6

[Frédéric Buclin]

comment 4 makes me think that the problem described here is very similar to the problem described in bug 307662 comment 8. Reopen if you disagree.

*** This bug has been marked as a duplicate of 307662 ***