| Bug #8897 | Test 'ndb_autodiscover': Spurious warning in '--ps-protocol' on NDB | ||
|---|---|---|---|
| Submitted: | 2 Mar 2005 18:33 | Modified: | 14 Mar 2005 12:17 |
| Reporter: | Joerg Bruehe | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 5.0.3-pre | OS: | many Unix |
| Assigned to: | Martin Skold | CPU Architecture: | Any |
[2 Mar 2005 19:00]
Joerg Bruehe
I suppose these are caused by the same error: ndb_autodiscover2 [ fail ] Errors are (from ...) : .../mysqltest: At line 9: unable to prepare statement 'select * from t9 order by a': Table 'test.t9' doesn't exist (mysql_stmt_errno=1146 returned=1) (the last lines may be the most important ones) ------------------------------------------------------- *** r/ndb_multi.result Tue Mar 1 18:53:33 2005 --- r/ndb_multi.reject Wed Mar 2 15:15:34 2005 *************** *** 15,20 **** --- 15,22 ---- Handler_discover 0 flush status; select * from t1; + Warnings: + Error 1146 Table 'test.t1' doesn't exist a 2 update t1 set a=3 where a=2; *************** *** 29,34 **** --- 31,38 ---- a 3 select * from t3; + Warnings: + Error 1146 Table 'test.t3' doesn't exist a b c last_col 1 Hi! 89 Longtext column show status like 'handler_discover%'; ------------------------------------------------------- ndb_restore [ fail ] Errors are (from ...) : .../mysqltest: At line 201: unable to prepare statement 'select count(*) from t9': Table 'test.t9' doesn't exist (mysql_stmt_errno=1146 returned=1) (the last lines may be the most important ones) ps_1general [ fail ] Errors are (from ...) : .../mysqltest: At line 961: query 'drop table t1,t9 ' failed: 1051: Unknown table 't9' (the last lines may be the most important ones)
[8 Mar 2005 11:12]
Martin Skold
This is not only when running with --ps-protocol same failures occur in a plain run with cluster tests on mysql-5.0 source tree.
[11 Mar 2005 6:41]
Martin Skold
With the push ChangeSet 1.1894, https://intranet.mysql.com/secure/mailarchive/mail.php?folder=5&mail=34712 the cluster test suite was broken. This fix changed the behavior so that openfrm() pushes warnings for previously ignored errors. This is incompatible with the cluster autodiscover functionality that provides limited distribution transparency of remotely created/dropped tables. I see four possible ways to solve this: 1) Remove the warnings only for autodiscovery, this requires either moving the autodiscover logic into openfrm() to determine when warnings should be pushed and when not or moving the pushing of warnings out of openfrm(). The first solution requires redesign of autodiscover logic since it uses openfrm() which could end up being recursive (not a good solution), this is also not a solution that can be ready in the near future. The second solution requires changing openfrm() so that it returns more information so the warnings can be built by the caller, and that code is added, in every place openfrm() is called, that pushes warnings if needed. The current autodiscover logic can then easily be fixed to make sure no warnings are pushed if tables are discovered through a handler. This is not an elegant solution, and also not trivial to implement. 2) Remove the warnings just for the specific call to openfrm(), this is a very simple fix, just toggle the thd->no_warnings_for_error on and off in open_unireg_entry(). There is, however, already a test for this warning in innodb.test that then fails. 3) After a successful autodiscovery the incorrect warning can be cleared. Currently there is no support to just pop the warning stack (not supported by underlying data structure). Forcing clearing of the warning stack is easy to add, this however is not totally correct since it will clear any warnings generated during the parsing (not a big deal since the warning will be gotten the next time the query is run anyway). 4) Back out the ChangeSet, probably not needed, since it is only part of the push that causes problems.
[14 Mar 2005 12:14]
Martin Skold
Did a fix according to solution 3) Created WL#2487 Rewrite autodiscovery, move into openfrm()
Description: Bug occurs on: FreeBSD 5.3 ('bsd53') and 4.7 ('cane'), Linux (i686: 'build', Alpha: 'ds20', S/390: 's390', x86_64: 'hammer', ia64 'ita2', PPC 'pegasos1'), HP-UX on HP-PA (11.00 'hp3750', 11.11 'hpux11'), IRIX ('octane2', both 32 and 64 bit), Mac OS X (10.2 'g4', 10.3 'g5'), Solaris / i386 (8 'intelxeon3', 9 'sol9x86'), Solaris / Sparc 10 ('butch'). Bug occurs only in '--ps-protocol' test run for 'max', previous default run passes for 'max' as well as both runs for 'standard'. Build is based on ChangeSet 1.1775 05/03/01 14:54:47 konstantin@mysql.com +1 -0 Fix for Bug#8801: the bug was in co-operation of Item_ref with view-merge algorithm and prepared statements: in case when some Item_ref pointing to a view column was substituted with a reference ... ------------------------------------------------------- *** r/ndb_autodiscover.result Tue Mar 1 18:53:32 2005 --- r/ndb_autodiscover.reject Wed Mar 2 15:08:57 2005 *************** *** 7,12 **** --- 7,14 ---- insert into t1 values(1, "Autodiscover"); flush tables; select * from t1; + Warnings: + Error 1146 Table 'test.t1' doesn't exist id name 1 Autodiscover show status like 'handler_discover%'; *************** *** 14,19 **** --- 16,23 ---- Handler_discover 1 flush tables; insert into t1 values (2, "Auto 2"); + Warnings: + Error 1146 Table 'test.t1' doesn't exist show status like 'handler_discover%'; Variable_name Value Handler_discover 2 *************** ... and more such differences until ... *************** *** 67,72 **** --- 77,84 ---- Handler_discover 0 flush tables; select * from t2; + Warnings: + Error 1296 Got error 3 'Unknown error code' from ndbcluster id name 1 Discoverer show status like 'handler_discover%'; *************** *** 285,290 **** --- 297,306 ---- insert into t4 values (4); flush tables; select * from t1, t2, t3, t4; + Warnings: + Error 1146 Table 'test.t1' doesn't exist + Error 1146 Table 'test.t2' doesn't exist + Error 1146 Table 'test.t3' doesn't exist id id b id c id 1 2 table 2 3 ndb table 3 4 show status like 'handler_discover%'; ------------------------------------------------------- How to repeat: Build + test. Tree for analysis is saved on 'build' as 'bug####' (number set when bug# is known).