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:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:5.0 OS:
Assigned to: CPU Architecture:Any

[12 Mar 2005 16:37] Sergey Petrunya
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
[14 Mar 2005 6:19] Tomas Ulin
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.

[14 Mar 2005 6:26] Tomas Ulin
sorry read the bug report wrong
[16 Mar 2005 16:55] Martin Skold
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 
Maybe a retry can be implemented higher up in the server architecture.
[24 Mar 2005 7:36] Martin Skold
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.