September 2010 - developers - lists.mariadb.org

[Maria-developers] request for feedback on live schema changes patch
by Zardosht Kasheff 18 Mar '11

18 Mar '11

Hello all, In another thread, there was a discussion about what it would take to allow the storage engine to support live schema changes in mysql and mariadb. I said that I was working porting this existing feature from MySQL Cluster to MySQL 5.1.46. I would like to show the work I have done so far and solicit feedback. Attached is the diff based off of 5.1.46. Before looking at the patch, please be aware of the following things: - I am not an expert in this code. As a result, I had to use an approach of that minimizes the risk of introducing regressions. \ - My main interest is to get something safe that works and can be integrated in 5.1. As a result, kept the current mysql_alter_table functionality in place (as old_mysql_alter_table), and added MySQL Cluster's as new_mysql_alter_table. For an engine to get new_mysql_alter_table to be used, the engine must expose an alter table flag HA_GENERAL_ONLINE. - Another reason why I kept old_mysql_alter_table was that I did not want to deal with engines that implement handler::add_index and make sure that they work properly under the new API. Also, I did not want to port alter table changes related to partitioned tables. - I have run the current 5,1 mysql test suite (that is in the mysql-test directory of source tarballs), and verified that using old_mysql_alter_table and new_mysql_alter_table works fine with them. That being said, I would love to hear feedback on this patch, and would also like to understand what (if anything) can be done to get this into MariaDB 5.1. I realize that may not be possible, but if it is, I would like to try. Thanks -Zardosht

2 5

[Maria-developers] Implementing new "group commit" API in PBXT?
by Kristian Nielsen 13 Dec '10

13 Dec '10

Hi Paul! I want to ask your opinion about implementing in PBXT an extension to the storage engine API that I am working on. There are lots of details in http://askmonty.org/worklog/Server-BackLog/?tid=116 (and even more details in other places), but I thought you would appreciate the short version :-) The idea is to get a well-defined ordering of commits in the server in an efficient way (eg. not break group commit like InnoDB does currently, Bug#13669). For this, two new (optional) storage engine methods are introduced: void (*prepare_ordered)(handlerton *hton, THD *thd, bool all); void (*commit_ordered)(handlerton *hton, THD *thd, bool all); The prepare_ordered() method is called after prepare(), as soon as commit order is decided. The commit_ordered() method is called before commit(), just after the transaction coordinator has made the final decision that the transaction will be durably committed (and not rolled back). The calls into commit_ordered() among different transactions will happen in the order that these transactions are committed, consistently across all engines and the binary log. Same for prepare_ordered(). The idea is that the storage engine should do the minimal amount of work in commit_ordered() necessary to make the commit visible to other threads. And to make sure commits appear to be done in the order of calls to these methods. Do you think either (or both) of these methods could be implemented in PBXT with reasonable effort (and if so, how)? ---- In InnoDB, this was trivial to do, as the InnoDB commit() method already had a "fast" part (which fixed the transaction log order (= "commit order") and made the transaction visible) and a "slow" part (which did the fsync() to make the transaction durable, and handled group commit). (It is necessary that commit_ordered() is fast, as it runs under a global lock. Ideally, it will just allocate an LSN in the transaction log to fix commit order, and perhaps whatever else already needs to happen serialised during engine commit). I hope my explanation was sufficiently clear for you to make a qualified answer. Maybe you can point me to where in the PBXT code a commit becomes visible and the commit order is fixed? In case you were wondering, here are some of the motivations for this feature: 1. For taking a hot backup, it is useful to have consistent commit order between binlog and storage engines. Without it, it can happen that the backed up state of the server has transaction A (but not B) committed in the storage engine, and transaction B (but not A) written to the binlog. Using such backup to provision a new master or slave would leave replication in an inconsistent state. 2. This feature implements working group commit for the binlog while still preserving consistent order as per (1). 3. This will allow to implement START TRANSACTION WITH CONSISTENT SNAPSHOT for multi-engine transactions that is truly consistent (currently is is possible for a transaction to be visible in one engine but not another in such "consistent" snapshot). 4. Galera relies on a consistent commit order, and I believe this feature will allow it to get this in a more engine-independent way. 5. We are planning to use consistent commit order to allow MySQL to recover after a crash transactions that were synced to disk in the binlog but not in the engine. This will allow to reduce the number of fsyncs() during prepare() / commit() from 3 to 1; it only needs to be done in the binlog (with group commit); the engine does not need to fsync(), as any lost transactions will be recovered from the binlog after crash. 6. The prepare_ordered() method is inspired by the Facebook patch to release InnoDB row-level read locks early (before syncing the binlog to disk) to improve performance in the presence of hot spots (probably does not apply to PBXT). - Kristian.

2 9

Re: [Maria-developers] Latest libmysqld.so patch
by Kristian Nielsen 05 Oct '10

05 Oct '10

Sergei Golubchik <serg(a)askmonty.org> writes: Thanks for review! What I would now like to do is to discuss how to proceeed (where to push this basically). On the one hand, the patch got rather more intrusive than I first wanted. The main issue is that now the mysys/mystrings/dbug code is linked dynamically by default, so these additional libmysys.so etc. libraries must be installed by packagers etc. for things to work; similarly extra -lmysys etc. is needed when using libmysqld.a. On the other hand, I think this is generally an improvement, linking code dynamically rather than statically. Saves duplicating code and so on, and dynamic linking is where the world is moving (has moved, really). I even tested the overhead of dynamic linking, it is two clock cycles per function call into a different library (I plan to write a short blog about that). So I think it is mainly a question on where we want to risk pushing this: 5.1, 5.2, or 5.3? We could even add it to the list of patches in the .debs for 5.1. (BTW, Gentoo people seems to have picked up the patch already in their MySQL and MariaDB 5.1 packages). And btw, I would like your help/hints on how to extend mysql_config to provide the right information for how to link. With those general remarks, here follow comments, inline: > Can I branch this your tree from somewhere ? bzr+ssh://bazaar.launchpad.net/~knielsen/maria/mariadb-5.1-mwl74-libmysqld.… >> The plugin may optionally specify @plugin_static_if_no_embedded@ in >> CFLAGS/CXXFLAGS for the static target; this will avoid needlessly >> compiling with -fPIC if no libmysqld is being built. > > I failed to understand this paragraph :( With this patch, every source file for a plugin is compiled twice, once with -fPIC and once without. However, if we are not building libmysqld, then the -fPIC versions will never be used. In this case, @plugin_static_if_no_embedded@ will add -static to CFLAGS, avoiding the needless compilations with -fPIC. Otherwise it will be empty. Hope this was clearer. [There is BTW another similar issue: when building a convenience library, libtool will again compile sources both with and without -fPIC. But it only ever uses the -fPIC objects in the convenience library, the objects without -fPIC are not used. I even tested the newest libtool version, and also found an email thread discussing this (and agreeing that the problem is there)]. >> This patch only does what is necessary to build libmysqld.so. There >> are some more cleanups that are possible now that we are using libtool >> more fully, which will be done in subsequent patches: >> >> - In libmysql_r/, we should be able to just link libmysys.la etc, >> instead of symlinking and re-compiling sources into the directory. >> >> - In libmysql/, we can similarly avoid symlinking and recompiling >> sources if we instead build a libmysys_nothread.la library with >> appropriate CFLAGS and link that. > > I'd rather not build libmysql at all. > Or, at least, not by default. Right, let's add this on top of this patch once we find out where we want to push it? If we link libmysql_r with libmysys, it will also solve another issue I have (with conflicts between C and assembler versions of bmovXXX); I postponed this issue until we decided about linking libmysql_r with mysys etc (it seems you agree we should do this). >> === modified file 'config/ac-macros/plugins.m4' >> --- config/ac-macros/plugins.m4 2010-09-18 07:53:48 +0000 >> +++ config/ac-macros/plugins.m4 2010-09-27 12:41:05 +0000 >> @@ -115,18 +115,32 @@ dnl ------------------------------------ >> dnl Macro: MYSQL_PLUGIN_STATIC >> dnl >> dnl SYNOPSIS >> -dnl MYSQL_PLUGIN_STATIC([name],[libmyplugin.a]) >> +dnl MYSQL_PLUGIN_STATIC([name],[libmyplugin.a],[libmyplugin_embedded.a]) >> dnl >> dnl DESCRIPTION >> -dnl Declare the name for the static library >> +dnl Declare the name for the static library >> +dnl >> +dnl Third argument is optional, only needed for special plugins that depend >> +dnl on server internals and have source files that must be compiled specially >> +dnl with -DEMBEDDED_LIBRARY for embedded server. If specified, the third >> +dnl argument is used to link embedded server instead of the second. > > Does that mean that all plugin files will be rebuilt with > -DEMBEDDED_LIBRARY if libmyplugin_embedded.a is specified ? No. It means that the plugin Makefile.am has the possibility to specify a different library to be used for embedded. Later in the patch I modify all plugins that need it (ie. they before specified MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS) so that they build a convenience library (once) with all the source files that do not depend on internals. And compile the few source files that do depend on internals in two versions with or without -DEMBEDDED_LIBRARY. And then link those together to two different libraries, one for server, one for embedded. With this, it's basically up to the plugin Makefile.am to do what it wants. >> -AC_DEFUN([MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS],[ >> - MYSQL_REQUIRE_PLUGIN([$1]) >> - m4_define([MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS_]AS_TR_CPP([$1]), [$2]) >> -]) > > I thought we agreed on IRC to keep it. > Do you mean, you tried it and it didn't work? Yes. I tried quite hard to find a way to keep compatibility. But failed :-( In the end I could not think of anything sensible to do for MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS(), so I removed it. This is related to your question below, about keeping compatibility so that eg. PBXT could still work unmodified between MySQL and MariaDB. I thought a lot about how to do this, but in the end failed. The hardest problem is that to link libmysqld.so with libtool, we need plugins to provide libXXX.la files in MYSQL_PLUGIN_STATIC(). And those libXXX.la simply will not work with the magic loop in MySQL sources that extracts objects from libXXX.a, removes duplicates, and links them back again. At least I couldn't see how to do it. So in the end I gave up on this compatibility. Sad, however a small comfort is that - This only hits plugins that say MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS(), which ideally they shouldn't anyway. - This only hits static plugins, which in any case need an incompatible maria_declare_plugin() added in the source (though this can be handled with #ifdef; I wonder if there is m4/automake equivalent ifdef that could help here?) If you have an idea on how to achieve compatibility and do something sensible for MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS(), then let me know ... >> +# __MYSQL_EMIT_CHECK_PLUGIN arguments: >> +# >> +# 1 - plugin identifying name >> +# 2 - plugin identifying name, with `-' replaced by `_' >> +# 3 - plugin long name >> +# 4 - plugin description >> +# 5 - mysql_plugin_define (eg. WITH_xxx_STORAGE_ENGINE) >> +# 6 - directory >> +# 7 - static target (if supports static build) >> +# 8 - dynamic target (if supports dynamic build) >> +# 9 - mandatory flag >> +# 10 - disabled flag >> +# 11 - static target for libmysqld (if different from mysqld) > > perhaps "if different from $7" ? Fixed, thanks. >> +# 12 - actions > > better use 'dnl' here, not '#' > > because '#'-lines will go into configure script, where they will mean > nothing, as the macro will be already expanded. Fixed >> +dnl If not building libmysqld embedded server, then there is no need to build >> +dnl shared object versions of static plugins. > > heh :) > There, on the contrary, I'd rather use '#' for comments, not 'dnl' Ok, I see, thanks for helping an m4 newbee :-) Fixed. >> === modified file 'configure.in' >> --- configure.in 2010-08-27 14:12:44 +0000 >> +++ configure.in 2010-09-13 20:17:09 +0000 >> @@ -2846,9 +2845,6 @@ if test "$with_server" != "no" -o "$THRE >> then >> AC_DEFINE([THREAD], [1], >> [Define if you want to have threaded code. This may be undef on client code]) >> - # Avoid _PROGRAMS names >> - THREAD_LOBJECTS="thr_alarm.o thr_lock.o thr_mutex.o thr_rwlock.o my_pthread.o my_thr_init.o mf_keycache.o mf_keycaches.o waiting_threads.o" >> - AC_SUBST(THREAD_LOBJECTS) > > What was that? Definitions for mysys/Makefile.am to know what to build > (or not) depending on whether threads are enabled ? Yes. This is fixing an inconsistency in the original sources. These source files should only be compiled when threads are enabled. There was code to deal with this in two places: here in configure.in, and in mysys/Makefile.am. Each place handled a different set of files, and there was overlap (maybe due to merge error?) Anyway, with pure static libraries, this overlap did not cause problems apparently, but with libtool and .so linking, it caused a failure. So I decided to clean it up to be done in one place only. >> === modified file 'dbug/Makefile.am' >> --- dbug/Makefile.am 2010-08-27 14:12:44 +0000 >> +++ dbug/Makefile.am 2010-09-28 11:23:14 +0000 >> @@ -16,10 +16,10 @@ >> # MA 02111-1307, USA >> >> INCLUDES = -I$(top_builddir)/include -I$(top_srcdir)/include >> -LDADD = libdbug.a ../mysys/libmysys.a ../strings/libmystrings.a >> -pkglib_LIBRARIES = libdbug.a >> +LDADD = libdbug.la ../mysys/libmysys.la ../strings/libmystrings.la > > better to use $(top_builddir)/libmysys.la etc > (here and below) Fixed (throughout the patch) > How's the build time - new, libmysql.so vs. the old libmysqld.a ? Thanks for remind me, I checked. These are on a quad-core with no ccache: BUILD/compile-pentium64-valgrind-max: Before: 3m19.454s After: 4m18.947s So build time _is_ increased somewhat ... > Paul would apparently want his engine to work both with MySQL and > MariaDB. Could we somehow make it possible (applies to other engines > too)? (See discussion above) Thanks, - Kristian.

2 1

[Maria-developers] Live Schema Changes
by Adam M. Dutko 04 Oct '10

04 Oct '10

I'm sure you have all read http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/tools/annotate… already, but if you haven't, it might be neat to look at evaluating and possibly integrating it into MariaDB.

5 9

[Maria-developers] Automatic annotated code coverage reports for MariaDB
by Philip Stoev 04 Oct '10

04 Oct '10

Hello everyone, I have now managed to make buildbot produce automatic LCOV reports for MariaDB. You can view them here http://fedora13.selfip.org/lcov/ and get statistics down to directory/file level or open an individual file and see an annotated listing showing lines that were not covered. The report is calculated based on a default MTR test run, plus PBXT and the funcs_x and other smaller test suites. No --big or binlog combinations are being used. RQG tests are not included, since the idea is to *always* have decent MTR coverage, with the RQG being used a secondary line of defense. My idea is to monitor the report periodically and look for considerable regressions in code coverage, which would include: - pushing new code or major patches to the core server that reduce the code coverage within the existing files - adding new subdirectories, modules or storage engines that do not come with new tests to cover the new ground Regardless of those reports, everyone is encouraged to use the personal code coverage tools, including mtr.pl --gcov and the DGcov script (http://forge.mysql.com/wiki/DGCov) to check the coverage of patches and commits before they are pushed. This will avoid painful scenarios where people are asked to provide code coverage later in the development process, which is always a bigger pain. The buildbot host is capable of building any other launchpad-based tree, so if you require lcov reports for a particular feature or storage engine that you are developing, please drop me a note and I will configure reports to be generated for your tree as well. Thank you. Philip Stoev

2 1

[Maria-developers] Release Notes for mariadb-5.2.2-gamma
by Daniel Bartholomew 29 Sep '10

29 Sep '10

All, I'm preparing the release notes for MariaDB 5.2.2 Gamma. Is there anything in particular I should mention? As usual I'll be picking stuff out of the changelog to put into the release notes, but if there's something I should make sure to mention, let me know. Thanks. -- Daniel Bartholomew Monty Program - http://askmonty.org

1 1

[Maria-developers] WL#150 New (by Sergei): Phone home: more data
by worklog-noreply＠askmonty.org 26 Sep '10

26 Sep '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Phone home: more data CREATION DATE..: Sun, 26 Sep 2010, 13:54 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: Sergei CATEGORY.......: Server-RawIdeaBin TASK ID........: 150 (http://askmonty.org/worklog/?tid=150) VERSION........: Server-5.3 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: This task is about collecting more information in the server (and presenting it via status variables or somehow) that is useful for phone home feature. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] Testing a query/subquery in various contexts
by Philip Stoev 24 Sep '10

24 Sep '10

Hello, It is known that the MySQL codebase suffers from numerous unforseen interactions between components, so that if we have a query X that works when executed stand-alone, it may still break if it is executed as, for example, INSERT ... SELECT . So, the Random Query Generator has a module that runs each generated query into different contexts. Here is the current list: - as CREATE|INSERT|REPLACE ... SELECT - as a prepared statement, twice - as a stored procedure, twice - as a UNION - converted into a VIEW The question is, what else is missing? I know about the following: - DELETE/UPDATE, etc. operations that involve the query as a subquery - triggers but what about trying to evaluate the query inside an IF, CASE, FOR , or anything else? If you have any suspicion that any of the code handles a particular situation or context differently, please let me know so that I can add it to the RQG. Thank you. Philip Stoev

1 0

[Maria-developers] MySQL 6.0 branches on launchpad
by Kristian Nielsen 24 Sep '10

24 Sep '10

Hi, As you know, MySQL is no longer working on the old MySQL 6.0 codebase. I noticed that the mysql-6.0-backup and mysql-6.0-codebase trees are no longer in ~mysql-server on Launchpad. Since there has been talk about backporting from 6.0 the backup and/or other features not yet in MySQL 5.5/5.6, I thought it might be useful for people to still have easy access to these trees, so I pushed them to ~maria on Launchpad: lp:~maria-captains/maria/mysql-6.0-backup lp:~maria-captains/maria/mysql-6.0-codebase - Kristian.

1 0

[Maria-developers] Removing very old options for --old, --new, --safe-mode
by Michael Widenius 23 Sep '10

23 Sep '10

Hi! I did notice that we haven't cleaned up the usage of the --old, --new, --safe-mode and --skip-new options in a long time. Here is a cleanup of this for MariaDB 5.2 (soon to be made gamma). After this suggested change, here is how the options would work: --new Use new functionality that will exist in next version of MariaDB. This function exist to make it easier to prepare for an upgrade. For version 5.1 this functions enables the LIST and RANGE partitions functions for ndbcluster. --old Use compatible behavior with previous main version for some functionality. For MariaDB 5.1 this means that we are using the old, MySQL 5.1 compatible, way to calculate checksums for records. If you are using --old, CHECKSUM TABLE will always do a full table scan. --safe_mode Disable some potential unsafe optimization. For 5.2 these are: INSERT DELAYED is disabled, myisam_recover_options is set to DEFAULT (automatically recover crashed MyISAM files). For Aria table, disable bulk insert optimization to enable one to use maria_read_log to recover tables even if tables are deleted (good for testing recovery). --skip-new Skip some new potentially unsafe functions. For 5.2 these are: INSERT DELAYED is disabled, Query cache size is reset. Here is the patch against MariaDB 5.2: === modified file 'sql/field.cc' --- sql/field.cc 2010-08-05 19:56:11 +0000 +++ sql/field.cc 2010-09-14 15:45:01 +0000 @@ -6703,8 +6703,7 @@ void Field_string::sql_type(String &res) length= cs->cset->snprintf(cs,(char*) res.ptr(), res.alloced_length(), "%s(%d)", - ((type() == MYSQL_TYPE_VAR_STRING && - !thd->variables.new_mode) ? + (type() == MYSQL_TYPE_VAR_STRING ? (has_charset() ? "varchar" : "varbinary") : (has_charset() ? "char" : "binary")), (int) field_length / charset()->mbmaxlen); === modified file 'sql/item_cmpfunc.cc' --- sql/item_cmpfunc.cc 2010-08-05 19:56:11 +0000 +++ sql/item_cmpfunc.cc 2010-09-14 16:41:01 +0000 @@ -4683,8 +4683,7 @@ bool Item_func_like::fix_fields(THD *thd We could also do boyer-more for non-const items, but as we would have to recompute the tables for each row it's not worth it. */ - if (args[1]->const_item() && !use_strnxfrm(collation.collation) && - !(specialflag & SPECIAL_NO_NEW_FUNC)) + if (args[1]->const_item() && !use_strnxfrm(collation.collation)) { String* res2 = args[1]->val_str(&cmp.value2); if (!res2) === modified file 'sql/mysqld.cc' --- sql/mysqld.cc 2010-08-24 22:44:50 +0000 +++ sql/mysqld.cc 2010-09-14 16:40:09 +0000 @@ -8725,11 +8725,7 @@ mysqld_get_one_option(int optid, case (int) OPT_SKIP_NEW: opt_specialflag|= SPECIAL_NO_NEW_FUNC; delay_key_write_options= (uint) DELAY_KEY_WRITE_NONE; - myisam_concurrent_insert=0; - myisam_recover_options= HA_RECOVER_NONE; - sp_automatic_privileges=0; - my_use_symdir=0; - ha_open_options&= ~(HA_OPEN_ABORT_IF_CRASHED | HA_OPEN_DELAY_KEY_WRITE); + ha_open_options&= ~(HA_OPEN_DELAY_KEY_WRITE); #ifdef HAVE_QUERY_CACHE query_cache_size=0; #endif === modified file 'sql/records.cc' --- sql/records.cc 2010-07-17 19:58:08 +0000 +++ sql/records.cc 2010-09-14 16:40:09 +0000 @@ -216,7 +216,6 @@ bool init_read_record(READ_RECORD *info, */ if (!disable_rr_cache && !table->sort.addon_field && - ! (specialflag & SPECIAL_SAFE_MODE) && thd->variables.read_rnd_buff_size && !(table->file->ha_table_flags() & HA_FAST_KEY_READ) && (table->db_stat & HA_READ_ONLY || === modified file 'sql/sql_delete.cc' --- sql/sql_delete.cc 2010-08-05 19:56:11 +0000 +++ sql/sql_delete.cc 2010-09-14 16:40:10 +0000 @@ -130,7 +130,6 @@ bool mysql_delete(THD *thd, TABLE_LIST * - there should be no delete triggers associated with the table. */ if (!using_limit && const_cond_result && - !(specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE)) && (thd->lex->sql_command == SQLCOM_TRUNCATE || (!thd->current_stmt_binlog_row_based && !(table->triggers && table->triggers->has_delete_triggers())))) === modified file 'sql/sql_parse.cc' --- sql/sql_parse.cc 2010-08-05 19:56:11 +0000 +++ sql/sql_parse.cc 2010-09-14 16:40:09 +0000 @@ -3086,9 +3086,7 @@ end_with_restore_list: goto error; /* purecov: inspected */ thd->enable_slow_log= opt_log_slow_admin_statements; thd->query_plan_flags|= QPLAN_ADMIN; - res= (specialflag & (SPECIAL_SAFE_MODE | SPECIAL_NO_NEW_FUNC)) ? - mysql_recreate_table(thd, first_table) : - mysql_optimize_table(thd, first_table, &lex->check_opt); + res= mysql_optimize_table(thd, first_table, &lex->check_opt); /* ! we write after unlocking the table */ if (!res && !lex->no_write_to_binlog) { === modified file 'sql/sql_select.cc' --- sql/sql_select.cc 2010-08-24 22:44:50 +0000 +++ sql/sql_select.cc 2010-09-14 16:39:57 +0000 @@ -7187,8 +7187,6 @@ eq_ref_table(JOIN *join, ORDER *start_or static bool only_eq_ref_tables(JOIN *join,ORDER *order,table_map tables) { - if (specialflag & SPECIAL_SAFE_MODE) - return 0; // skip this optimize /* purecov: inspected */ tables&= ~PSEUDO_TABLE_BITS; for (JOIN_TAB **tab=join->map2table ; tables ; tab++, tables>>=1) { ------------- Any comments ? Regards, Monty

2 2