-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
‘TRUE’ was not declared in this scope #4
Comments
We have fixed TRUE/FALSE compile problem, reopen it if any problem again. |
still the same error [ 78%] Building CXX object sql/CMakeFiles/sql_main.dir/sys_vars.cc.o
In file included from /home/ubuntu/develop/galaxyengine/sql/sys_vars.cc:44:0:
/home/ubuntu/develop/galaxyengine/sql/sys_vars.cc:6785:66: error: ‘FALSE’ was not declared in this scope
SESSION_ONLY(sequence_read_skip_cache), NO_CMD_LINE, DEFAULT(FALSE),
^
/home/ubuntu/develop/galaxyengine/sql/sys_vars.h:102:20: note: in definition of macro ‘DEFAULT’
#define DEFAULT(X) X
^
/home/ubuntu/develop/galaxyengine/sql/sys_vars.cc:6785:66: note: suggested alternative: ‘FILE’
SESSION_ONLY(sequence_read_skip_cache), NO_CMD_LINE, DEFAULT(FALSE),
^
/home/ubuntu/develop/galaxyengine/sql/sys_vars.h:102:20: note: in definition of macro ‘DEFAULT’
#define DEFAULT(X) X
^
/home/ubuntu/develop/galaxyengine/sql/sys_vars_ext.cc:263:48: error: ‘FALSE’ was not declared in this scope
DEFAULT(FALSE), NO_MUTEX_GUARD,
^
/home/ubuntu/develop/galaxyengine/sql/sys_vars.h:102:20: note: in definition of macro ‘DEFAULT’
#define DEFAULT(X) X |
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
…TH VS 2019 [#4] [noclose] storage\ndb\src\ndbapi\ObjectMap.hpp(168,1): warning C4302: 'type cast': truncation from 'void *' to 'long' Change-Id: I11ffba127bc19db15e9a50307b50532941f9fdb2
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
Increment the "start_stmt_count" variable only when handler has been registered sucessfully and thus remove two unneccessary decrement calls. Improve description of the "start_stmt_count" variable. Change-Id: I50f269fb024002a122cf898c84fb578c50007980
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
…close] Make the range optimizer return AccessPaths instead of TABLE_READ_PLAN. This is the first step of getting rid of TABLE_READ_PLAN and moving everything into AccessPath; currently, it's just a very thin shell: 1. TRPs are still used internally, and AccessPath is created at the very end. 2. Child TRPs are still child TRPs (ie., there are no child AccessPaths). 3. All returned AccessPaths are still of the type INDEX_RANGE_SCAN, wrapping a TRP. 4. Some callers still reach directly into the TRP, assuming #3. Most callers (save for the aforemented #4) use a set of simple wrapper functions to access TRP-derived properties from AccessPaths; as we continue the transformation, this is the main place we'll change the interaction (ie., most of the calling code will remain unchanged). Change-Id: I3d9dc9e33c53d1e5124ea9c47b7d6d9270cd1906
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
Patch #4: Wrong results with AND of JSON_CONTAINS and multi-valued indexes For a multi-valued index on json array field f=[1, 2], this statement wrongly returned empty result set: SELECT * FROM f WHERE JSON_CONTAINS(f, 1) AND JSON_CONTAINS(f, 2); The cause is that get_func_mm_tree() converts two JSON_CONTAINS() to `f_idx = 1 AND f_idx = 2` which is always false for single value index but possible for multi-valued index. Fixed by anding the two key ranges, rather than marking the condition as always false. This is a contribution by Yubao Liu. Change-Id: I535fc6ce8755f4f3b6e8cbd77b4c0ee4aa685cae
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
This error happens for queries such as: SELECT ( SELECT 1 FROM t1 ) AS a, ( SELECT a FROM ( SELECT x FROM t1 ORDER BY a ) AS d1 ); Query_block::prepare() for query block #4 (corresponding to the 4th SELECT in the query above) calls setup_order() which again calls find_order_in_list(). That function replaces an Item_ident for 'a' in Query_block.order_list with an Item_ref pointing to query block #2. Then Query_block::merge_derived() merges query block #4 into query block #3. The Item_ref mentioned above is then moved to the order_list of query block #3. In the next step, find_order_in_list() is called for query block #3. At this point, 'a' in the select list has been resolved to another Item_ref, also pointing to query block #2. find_order_in_list() detects that the Item_ref in the order_list is equivalent to the Item_ref in the select list, and therefore decides to replace the former with the latter. Then find_order_in_list() calls Item::clean_up_after_removal() recursively (via Item::walk()) for the order_list Item_ref (since that is no longer needed). When calling clean_up_after_removal(), no Cleanup_after_removal_context object is passed. This is the actual error, as there should be a context pointing to query block #3 that ensures that clean_up_after_removal() only purge Item_subselect.unit if both of the following conditions hold: 1) The Item_subselect should not be in any of the Item trees in the select list of query block #3. 2) Item_subselect.unit should be a descendant of query block #3. These conditions ensure that we only purge Item_subselect.unit if we are sure that it is not needed elsewhere. But without the right context, query block #2 gets purged even if it is used in the select lists of query blocks #1 and #3. The fix is to pass a context (for query block #3) to clean_up_after_removal(). Both of the above conditions then become false, and Item_subselect.unit is not purged. As an additional shortcut, find_order_in_list() will not call clean_up_after_removal() if real_item() of the order item and the select list item are identical. In addition, this commit changes clean_up_after_removal() so that it requires the context to be non-null, to prevent similar errors. It also simplifies Item_sum::clean_up_after_removal() by removing window functions unconditionally (and adds a corresponding test case). Change-Id: I449be15d369dba97b23900d1a9742e9f6bad4355
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
Change-Id: I579c2691165865101559915239b2cd027c10ab56
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
The NdbEventOperationImpl owns a NdbDictionary::Event by having a pointer to the Event's implementation. Make sure the pointer is always initialized in constructor and mark the pointer const. Also mark NdbEventImpl's pointer to the Event as const. Thus the m_eventImpl->m_facade pointer path should now be enforced by compiler. Change-Id: I469b39d66a4d83daf08307d980d555da1ab79827
xiewajueji
pushed a commit
that referenced
this issue
May 5, 2024
-- Patch #1: Persist secondary load information -- Problem: We need a way of knowing which tables were loaded to HeatWave after MySQL restarts due to a crash or a planned shutdown. Solution: Add a new "secondary_load" flag to the `options` column of mysql.tables. This flag is toggled after a successful secondary load or unload. The information about this flag is also reflected in INFORMATION_SCHEMA.TABLES.CREATE_OPTIONS. -- Patch #2 -- The second patch in this worklog triggers the table reload from InnoDB after MySQL restart. The recovery framework recognizes that the system restarted by checking whether tables are present in the Global State. If there are no tables present, the framework will access the Data Dictionary and find which tables were loaded before the restart. This patch introduces the "Data Dictionary Worker" - a MySQL service recovery worker whose task is to query the INFORMATION_SCHEMA.TABLES table from a separate thread and find all tables whose secondary_load flag is set to 1. All tables that were found in the Data Dictionary will be appended to the list of tables that have to be reloaded by the framework from InnoDB. If an error occurs during restart recovery we will not mark the recovery as failed. This is done because the types of failures that can occur when the tables are reloaded after a restart are less critical compared to previously existing recovery situations. Additionally, this code will soon have to be adapted for the next worklog in this area so we are proceeding with the simplest solution that makes sense. A Global Context variable m_globalStateEmpty is added which indicates whether the Global State should be recovered from an external source. -- Patch #3 -- This patch adds the "rapid_reload_on_restart" system variable. This variable is used to control whether tables should be reloaded after a restart of mysqld or the HeatWave plugin. This variable is persistable (i.e., SET PERSIST RAPID_RELOAD_ON_RESTART = TRUE/FALSE). The default value of this variable is set to false. The variable can be modified in OFF, IDLE, and SUSPENDED states. -- Patch #4 -- This patch refactors the recovery code by removing all recovery-related code from ha_rpd.cc and moving it to separate files: - ha_rpd_session_factory.h/cc: These files contain the MySQLAdminSessionFactory class, which is used to create admin sessions in separate threads that can be used to issue SQL queries. - ha_rpd_recovery.h/cc: These files contain the MySQLServiceRecoveryWorker, MySQLServiceRecoveryJob and ObjectStoreRecoveryJob classes which were previously defined in ha_rpd.cc. This file also contains a function that creates the RecoveryWorkerFactory object. This object is passed to the constructor of the Recovery Framework and is used to communicate with the other section of the code located in rpdrecoveryfwk.h/cc. This patch also renames rpdrecvryfwk to rpdrecoveryfwk for better readability. The include relationship between the files is shown on the following diagram: rpdrecoveryfwk.h◄──────────────rpdrecoveryfwk.cc ▲ ▲ │ │ │ │ │ └──────────────────────────┐ │ │ ha_rpd_recovery.h◄─────────────ha_rpd_recovery.cc──┐ ▲ │ │ │ │ │ │ │ │ │ ▼ │ ha_rpd.cc───────────────────────►ha_rpd.h │ ▲ │ │ │ ┌───────────────────────────────┘ │ │ ▼ ha_rpd_session_factory.cc──────►ha_rpd_session_factory.h Other changes: - In agreement with Control Plane, the external Global State is now invalidated during recovery framework startup if: 1) Recovery framework recognizes that it should load the Global State from an external source AND, 2) rapid_reload_on_restart is set to OFF. - Addressed review comments for Patch #3, rapid_reload_on_restart is now also settable while plugin is ON. - Provide a single entry point for processing external Global State before starting the recovery framework loop. - Change when the Data Dictionary is read. Now we will no longer wait for the HeatWave nodes to connect before querying the Data Dictionary. We will query it when the recovery framework starts, before accepting any actions in the recovery loop. - Change the reload flow by inserting fake global state entries for tables that need to be reloaded instead of manually adding them to a list of tables scheduled for reload. This method will be used for the next phase where we will recover from Object Storage so both recovery methods will now follow the same flow. - Update secondary_load_dd_flag added in Patch #1. - Increase timeout in wait_for_server_bootup to 300s to account for long MySQL version upgrades. - Add reload_on_restart and reload_on_restart_dbg tests to the rapid suite. - Add PLUGIN_VAR_PERSIST_AS_READ_ONLY flag to "rapid_net_orma_port" and "rapid_reload_on_restart" definitions, enabling their initialization from persisted values along with "rapid_bootstrap" when it is persisted as ON. - Fix numerous clang-tidy warnings in recovery code. - Prevent suspended_basic and secondary_load_dd_flag tests to run on ASAN builds due to an existing issue when reinstalling the RAPID plugin. -- Bug#33752387 -- Problem: A shutdown of MySQL causes a crash in queries fired by DD worker. Solution: Prevent MySQL from killing DD worker's queries by instantiating a DD_kill_immunizer before the queries are fired. -- Patch #5 -- Problem: A table can be loaded before the DD Worker queries the Data Dictionary. This means that table will be wrongly processed as part of the external global state. Solution: If the table is present in the current in-memory global state we will not consider it as part of the external global state and we will not process it by the recovery framework. -- Bug#34197659 -- Problem: If a table reload after restart causes OOM the cluster will go into RECOVERYFAILED state. Solution: Recognize when the tables are being reloaded after restart and do not move the cluster into RECOVERYFAILED. In that case only the current reload will fail and the reload for other tables will be attempted. Change-Id: Ic0c2a763bc338ea1ae6a7121ff3d55b456271bf0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The lastest commit log is
The error message of
make -j8
is[ 78%] Building CXX object sql/CMakeFiles/sql_main.dir/trans_proc/implicit_savepoint.cc.o In file included from /home/ubuntu/develop/galaxyengine/include/template_utils.h:28:0, from /home/ubuntu/develop/galaxyengine/include/m_ctype.h:46, from /home/ubuntu/develop/galaxyengine/sql/sql_parse.h:30, from /home/ubuntu/develop/galaxyengine/sql/trans_proc/implicit_savepoint.cc:21: /home/ubuntu/develop/galaxyengine/sql/trans_proc/implicit_savepoint.cc: In member function ‘virtual bool im::Sql_cmd_trans_proc_implicit_savepoint::pc_execute(THD*)’: /home/ubuntu/develop/galaxyengine/sql/trans_proc/implicit_savepoint.cc:59:17: error: ‘TRUE’ was not declared in this scope DBUG_RETURN(TRUE); ^ /home/ubuntu/develop/galaxyengine/include/my_dbug.h:156:13: note: in definition of macro ‘DBUG_RETURN’ return (a1); \ ^~ /home/ubuntu/develop/galaxyengine/sql/trans_proc/implicit_savepoint.cc:65:17: error: ‘TRUE’ was not declared in this scope DBUG_RETURN(TRUE);
The text was updated successfully, but these errors were encountered: