MySQL Bugs: #9144: Error 241 'Invalid schema object version' after table recreated in other client

Bug #9144	Error 241 'Invalid schema object version' after table recreated in other client
Submitted:	12 Mar 2005 16:37	Modified:	24 Mar 2005 7:36
Reporter:	Sergey Petrunya	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	5.0	OS:
Assigned to:		CPU Architecture:	Any

Description:
A SELECT from ndb table returns 
error 241 'Invalid schema object version' from ndbcluster
if the accessed table was dropped and recreated by another client since the current client accessed it last time.

Last tree cset: 
ChangeSet@1.1777, 2005-03-04 20:21:02+01:00, tomas@poseidon.ndb.mysql.com

How to repeat:
Start cluster, start one mysqld, start 2 mysql clients (client1 and client2) and perform the following commands:

client1> create table t1 (a int) engine=ndb;
client1> insert into t1 values (1);
client2> select * from t1;
-- works ok
client1> drop table t1;
client1> create table t1 (a int) engine=ndb;
client1> insert into t1 values (1);

client2> select * from t1;
ERROR 1296 (HY000): Got error 241 'Invalid schema object version' from ndbcluster
-- now we get an error.
-- we don't get this error with e.g. innodb. 
client2> select * from t1;
-- next time it works

This is partially a design choice and partially a result of the way the mysql server works...

1. There is currently no "push" mechanism to distribute meta data changes to the mysql servers.
2. We don't wan't to go and ask the cluster about meat datachanges before each statement, it's to expesive.
3. There is no "global" locking mechanism, for locking a table during an alter table, so this can happen even if we did 1. or 2.
4. We can not in the general case "retry automatically" with the new table version, since it might be the 2:nd table used in the transaction, and it is not until this is accessed, that the invalid table schema version is discovered - ndb cluster does not support partial rollback of a transaction.

Tomas

sorry read the bug report wrong

No, Tomas comments are correct, we currently detect schema changes
(alter tables) in a lazy manner, i.e. changes are currently not pushed out
and saving enough information in the handler for a retry would be too 
expensive.
Maybe a retry can be implemented higher up in the server architecture.

This was already reported in bug#8753.
Getting this error is not really a bug, but
it should dissapear after a retry. Implementing
automatic retries is a feauture request and
requires we implement this functionality above
the handler, since complete information about
the statement to retry is not available on that level.
In bug#8753 a real bug was found that if referencing
stale indexes a retry did not help since the cache was
not properly invalidated for indexes (only tables), this
is now fixed.