While running a full regression to ensure I hadn't broken anything, I found that test105 sometimes failed.

The failure is caused by something having to do with an auto-increment column and the DBRM. a lock isn't released properly and the DBRM asserts and shuts down. Recovery doesn't work and a restart is needed.

I'm guessing that an alter table to add an auto-increment is what's causing the issue. It's also possible that this is masked by release code (I'm using debug), but that doesn't mean it isn't ready to pounce at a customer site.

working_dml/misc/autoincrement.negative.sql

The test contains:

Alter table foo add column newcol bigint comment 'autoincrement';
select min(newcol), max(newcol) from foo;
select callastinsertid('foo');
Alter table foo change column newcol newcol bigint;

This last alter changing the column instigates the problem.

Dbrm.releaseAILock() is being called twice at altertableprocessor.cpp:988
Boost now asserts when deleting a mutex that has been released twice without an intervening lock()

See previous comment. Also, MCOL-259 and MCOL-261 weres affecting test005.

Review done. Looks great to me. Especially all the extra debugging in there.

Assigned to Daniel for QA but not sure there is any real test we can do here. It might just need closing off.

Assigned to Mr. Hill to check with regression results.

Thanks

test005 passing now..

test005 passing regression testing