Bug #39228 renaming a table underneath a merge scrambles the table

Description:
One problem I've run into with a merge table, in version 3.23, has to do with renaming a partition underneath the merge.  Basically, it corrupts the underlying table every time.  My script ran a check before and after renaming the component table, and the first one always showed it was OK, and the second one always showed it was corrupt (always a length error on the table).   If I dropped the merge table before doing the rename, it worked fine.

Since dropping the merge table is not something I want to do in a production environment, I've settled instead on a plan to keep track of a version number for each partition, and construct a new table called partition_vn.  Then I redefine the union parameter of the merge table, to include that new version rather than the old one, and drop the old copy of that partition, and all is well.

I note this bug might not be present in later mysql versions.

How to repeat:
Construct tables A and B, and a merge of them, call it AB.  Then construct a similar table A_new.  Run a check on that table to confirm it's OK.  Now do a rename table A to A_old, A_new to A.  Now run the check on A, and you will get an error.  If you remove the merge table AB before doing the rename, and then re-establish it afterward, it works fine.

Suggested fix:
When the partition table is renamed, evidently something has to be updated in the merge table info, apparently having to do with the size of the partition file.  It would appear this update is not occurring properly.  I don't know enough about the internals to comment further.

Thank you for the report.

But version 3.23 is not supported anymore. Please see http://www.mysql.com/about/legal/lifecycle/#calendar for details. Additionally I can not repeat described behavior with current GA version 5.0. so I close the report as "Unsupported".