- 11 Sep, 2012 1 commit
-
-
Joerg Bruehe authored
Bug #14181049: MYSQL_INSTALL_DB.PL CREATES EMPTY SYSTEM TABLES FOR MYSQL The script is different from what's used on unixes. It was not playing the table insertion script (mysql_system_tables_data.sql), although it was checking for the presence of this script. Fixed by re-enabling the lookup for this file and replaying it at bootstrap time. Note that on the Unixes "SELECT @@hostname" does return a fully qualified name, whereas on Windows it returns only a hostname. So by default we're filtering records in the mysql.user table until we ensure this is fixed. The change was coded in 5.5 by Georgi Kodinov <Georgi.Kodinov@Oracle.com>
-
- 10 Sep, 2012 2 commits
-
-
Andrei Elkin authored
-
Andrei Elkin authored
An "orthographic" typo in User_var::set_deferred() was made in fixes for bug@14275000. While editing the signature of the initial patch to remove the only argument, the assigned value of the argument remained in the body ... to be successfully compiled (!) thanks to names coincidence: the arg to User_var method and its member. Fixed with correcting the typo.
-
- 07 Sep, 2012 1 commit
-
-
akhil.mohan@oracle.com authored
-
- 05 Sep, 2012 1 commit
-
-
Tor Didriksen authored
In fill_schema_table_by_open(): free item list before restoring active arena.
-
- 03 Sep, 2012 1 commit
-
-
mysql-builder@oracle.com authored
No commit message
-
- 31 Aug, 2012 2 commits
-
-
Annamalai Gurusami authored
THOUGH IT IS NOT. The following error message is misleading because it claims that the BLOB space is not counted. "ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs" When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used, the BLOB prefix is stored inline along with the row. So the above error message is changed as follows depending on the row format used: For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error message is as follows: "ERROR 42000: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline." For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error message is as follows: "ERROR 42000: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline." rb://1252 approved by Marko Makela
-
mysql-builder@oracle.com authored
No commit message
-
- 30 Aug, 2012 2 commits
-
-
Marko Mäkelä authored
PAGE SPLIT page_rec_get_nth_const(): Map nth==0 to the page infimum. btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor should never be positioned on the page infimum. btr_index_page_validate(): Add test instrumentation for checking the return values of page_rec_get_nth_const() during CHECK TABLE, and for checking that the page directory slot 0 always contains only one record, the predefined page infimum record. page_cur_delete_rec(), page_delete_rec_list_end(): Add debug assertions guarding against accessing the page slot 0. page_copy_rec_list_start(): Clarify a comment about ret_pos==0. rb:1248 approved by Jimmy Yang
-
Marko Mäkelä authored
ha_innodb::records_in_range(): Remove a debug assertion that prohibits an open range (full table). The patch by Jorgen Loland only removed the assertion from the built-in InnoDB, not from the InnoDB Plugin.
-
- 28 Aug, 2012 1 commit
-
-
Jorgen Loland authored
ha_innobase::records_in_range(): Remove a debug assertion that prohibits an open range (full table). This assertion catches unnecessary calls to this method, but such calls are not harming correctness.
-
- 21 Aug, 2012 1 commit
-
-
Marko Mäkelä authored
HEURISTICS FOR COMPRESSED PAGE SIZE The fix of Bug#12845774 was supposed to skip known-to-fail btr_cur_optimistic_insert() calls. There was only one such call, in btr_cur_pessimistic_update(). All other callers of btr_cur_pessimistic_insert() would release and reacquire the B-tree page latch before attempting the pessimistic insert. This would allow other threads to restructure the B-tree, allowing (and requiring) the insert to succeed as an optimistic (single-page) operation. Failure to attempt an optimistic insert before a pessimistic one would trigger an attempt to split an empty page. rb:1234 approved by Sunny Bains
-
- 20 Aug, 2012 2 commits
-
-
Mattias Jonsson authored
pre-push fix, removed unused variable.
-
Mattias Jonsson authored
-
- 17 Aug, 2012 2 commits
-
-
Mattias Jonsson authored
Additional patch to remove the part_id -> ref_buffer offset. The partitioning id and the associate record buffer can be found without having to calculate it. By initializing it for each used partition, and then reuse the key-buffer from the queue, it is not needed to have such map.
-
Alexander Barkov authored
-
- 16 Aug, 2012 3 commits
-
-
Marko Mäkelä authored
Facebook got a case where the page compresses really well so that btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record gets updated, the compression rate radically changes so that btr_cur_insert_if_possible() can not insert in place despite reorganizing/recompressing the page, leading to the assertion failing. rb:1220 approved by Sunny Bains
-
Marko Mäkelä authored
COMPRESSED PAGE SIZE This was submitted as MySQL Bug 61456 and a patch provided by Facebook. This patch follows the same idea, but instead of adding a parameter to btr_cur_pessimistic_insert(), we simply remove the btr_cur_optimistic_insert() call there and add it to the only caller that needs it. btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert(). btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert() before invoking btr_cur_pessimistic_insert(). btr_cur_pessimistic_update(): Clarify in a comment why it is not necessary to invoke btr_cur_optimistic_insert(). btr_root_raise_and_insert(): Assert that the root page is not empty. This could happen if a pessimistic insert (involving a split or merge) is performed without first attempting an optimistic (intra-page) insert. rb:1219 approved by Sunny Bains
-
Marko Mäkelä authored
btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may fail after reorganizing the page. btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages, because compression may fail after reorganization. page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the ret_pos, which may also be the page infimum. rb:1221
-
- 15 Aug, 2012 1 commit
-
-
Mattias Jonsson authored
The buffer for the current read row from each partition (m_ordered_rec_buffer) used for sorted reads was allocated on open and freed when the ha_partition handler was closed or destroyed. For tables with many partitions and big records this could take up too much valuable memory. Solution is to only allocate the memory when it is needed and free it when nolonger needed. I.e. allocate it in index_init and free it in index_end (and to handle failures also free it on reset, close etc.) Also only allocating needed memory, according to partitioning pruning. Manually tested that it does not use as much memory and releases it after queries.
-
- 14 Aug, 2012 1 commit
-
-
Sujatha Sivakumar authored
MASTER-MASTER AND USING SET USE Problem: ======= In a master-master set-up, a master can show a wrong 'SHOW SLAVE STATUS' output. Requirements: - master-master - log_slave_updates This is caused when using SET user-variables and then using it to perform writes. From then on the master that performed the insert will have a SHOW SLAVE STATUS that is wrong and it will never get updated until a write happens on the other master. On"Master A" the "exec_master_log_pos" is not getting updated. Analysis: ======== Slave receives a "User_var" event from the master and after applying the event, when "log_slave_updates" option is enabled the slave tries to write this applied event into its own binary log. At the time of writing this event the slave should use the "originating server-id". But in the above case the sever always logs the "user var events" by using its global server-id. Due to this in a "master-master" replication when the event comes back to the originating server the "User_var_event" doesn't get skipped. "User_var_events" are context based events and they always follow with a query event which marks their end of group. Due to the above mentioned problem with "User_var_event" logging the "User_var_event" never gets skipped where as its corresponding "query_event" gets skipped. Hence the "User_var" event always waits for the next "query event" and the "Exec_master_log_position" does not get updated properly. Fix: === `MYSQL_BIN_LOG::write' function is used to write events into binary log. Within this function a new object for "User_var_log_event" is created and this new object is used to write the "User_var" event in the binlog. "User var" event is inherited from "Log_event". This "Log_event" has different overloaded constructors. When a "THD" object is present "Log_event(thd,...)" constructor should be used to initialise the objects and in the absence of a valid "THD" object "Log_event()" minimal constructor should be used. In the above mentioned problem always default minimal constructor was used which is incorrect. This minimal constructor is replaced with "Log_event(thd,...)".
-
- 11 Aug, 2012 1 commit
-
-
Venkata Sidagam authored
CONNECTIONS IF SPE Problem description: -ssl-key value is not validated, you can assign any bogus text to --ssl-key and it is not verified that it exists, and more importantly, it allows the client to connect to mysqld. Fix: Added proper validations checks for --ssl-key. Note: 1) Documentation changes require for 5.1, 5.5, 5.6 and trunk in the sections listed below and the details are : http://dev.mysql.com/doc/refman/5.6/en/ssl-options.html#option_general_ssl and REQUIRE SSL section of http://dev.mysql.com/doc/refman/5.6/en/grant.html 2) Client having with option '--ssl', should able to get ssl connection. This will be implemented as part of separate fix in 5.6 and trunk.
-
- 09 Aug, 2012 4 commits
-
-
Sergey Glukhov authored
When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
IN QUERIES This bug was caused by an incorrect fix of Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD There was nothing wrong with btr_pcur_restore_position(), but with the use of it in the table scan during index creation. rb:1206 approved by Jimmy Yang
-
Sunanda Menon authored
-
- 08 Aug, 2012 1 commit
-
-
Rohit Kalhans authored
WHEN STDIN IS A PIPE Problem: Mysqlbinlog does not accept the input from STDIN when STDIN is a pipe. This prevents the users from passing the input file through a shell pipe. Background: The my_seek() function does not check if the file descriptor passed to it is regular (seekable) file. The check_header() function in mysqlbinlog calls the my_b_seek() unconditionally and it fails when the underlying file is a PIPE. Resolution: We resolve this problem by checking if the underlying file is a regular file by using my_fstat() before calling my_b_seek(). If the underlying file is not seekable we skip the call to my_b_seek() in check_header().
-
- 07 Aug, 2012 2 commits
-
-
Nirbhay Choubey authored
SHOW 2012 INSTEAD OF 2011 * Added a new macro to hold the current year : COPYRIGHT_NOTICE_CURRENT_YEAR * Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro to take the initial year as parameter and pick current year from the above mentioned macro.
-
Harin Vadodaria authored
AND LIBCRYPTO Problem: libmysqlclient_r exports symbols from yaSSL library which conflict with openSSL symbols. This issue is related to symbols used by CURL library and are defined in taocrypt. Taocrypt has dummy implementation of these functions. Due to this when a program which uses libcurl library functions is compiled using libmysqlclient_r and libcurl, it hits segmentation fault in execution phase. Solution: MySQL should not be exporting such symbols. However, these functions are not used by MySQL code at all. So avoid compiling them in the first place.
-
- 05 Aug, 2012 1 commit
-
-
Chaithra Gopalareddy authored
Backport the fix from 5.6 to 5.1 Base bug number : 11765562
-
- 31 Jul, 2012 1 commit
-
-
Joerg Bruehe authored
-
- 27 Jul, 2012 2 commits
-
-
Tor Didriksen authored
Space available for merging was calculated incorrectly.
-
Venkata Sidagam authored
Fixed the missing of federated/include folder at the time of preparing package distribution, issue happens only in 5.1
-
- 26 Jul, 2012 5 commits
-
-
Praveenkumar Hulakund authored
IS PLACE HOLDER AND USE SERVER-SIDE Analysis: LIMIT always takes nonnegative integer constant values. http://dev.mysql.com/doc/refman/5.6/en/select.html So parsing of value '5' for LIMIT in SELECT fails. But, within prepared statement, LIMIT parameters can be specified using '?' markers. Value for the parameter can be supplied while executing the prepared statement. Passing string values, float or double value for LIMIT works well from CLI. Because, while setting the value for the parameters from the variable list (added using SET), if the value is for parameter LIMIT then its converted to integer value. But, when prepared statement is executed from the other interfaces as J connectors, or C applications etc. The value for the parameters are sent to the server with execute command. Each item in log has value and the data TYPE. So, While setting parameter value from this log, value is set to all the parameters with the same data type as passed. But here logic to convert value to integer type if its for LIMIT parameter is missing. Because of this,string '5' is set to LIMIT. And the same is logged into the binlog file too. Fix: When executing prepared statement having parameter for CLI it worked fine, as the value set for the parameter is converted to integer. And this failed in other interfaces as J connector,C Applications etc as this conversion is missing. So, as a fix added check while setting value for the parameters. If the parameter is for LIMIT value then its converted to integer value.
-
Venkata Sidagam authored
Fix for pb2 test failure.
-
Nirbhay Choubey authored
WORK + SAVES ROOT PASSWORD TO DISK! The secure installation scripts connect to the server by storing the password in a temporary option file. Now, if the script gets killed or fails for some reason, the removal of the option file may not take place. This patch introduces following enhancements : * (.sh) Made sure that cleanup happens at every call to 'exit 1'. This is performed implicitly by END{} in pl.in. * (.pl.in) Added a warning in case unlink fails to delete the option/query files. * (.sh/.pl.in) Added more signals to the signal handler list. SIG# 1, 3, 6, 15
-
Tor Didriksen authored
-
Venkata Sidagam authored
Problem description: Table 't' created with two colums having compound index on both the columns under innodb/myisam engine at remote machine. In the local machine same table is created undet the federated engine. A select having where clause with along 'AND' operation gives wrong results on local machine. Analysis: The given query at federated engine is wrongly transformed by federated::create_where_from_key() function and the same was sent to the remote machine. Hence the local machine is showing wrong results. Given query "select c1 from t where c1 <= 2 and c2 = 1;" Query transformed, after ha_federated::create_where_from_key() function is: SELECT `c1`, `c2` FROM `t` WHERE (`c1` IS NOT NULL ) AND ( (`c1` >= 2) AND (`c2` <= 1) ) and the same sent to real_query(). In the above the '<=' and '=' conditions were transformed to '>=' and '<=' respectively. ha_federated::create_where_from_key() function behaving as below: The key_range is having both the start_key and end_key. The start_key is used to get "(`c1` IS NOT NULL )" part of the where clause, this transformation is correct. The end_key is used to get "( (`c1` >= 2) AND (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') are changed as wrong conditions('>=' and '<='). The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, flag = HA_READ_AFTER_KEY} The store_length is having value '5'. Based on store_length and length values the condition values is applied in HA_READ_AFTER_KEY switch case. The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, here the '>=' is getting added as a condition instead of '<='. Fix: Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in the if condition.
-
- 25 Jul, 2012 1 commit
-
-
Annamalai Gurusami authored
Backporting the WL#5716, "Information schema table for InnoDB buffer pool information". Backporting revisions 2876.244.113, 2876.244.102 from mysql-trunk. rb://1175 approved by Jimmy Yang.
-
- 24 Jul, 2012 1 commit
-
-
Alexander Barkov authored
while the copyright notice still mentioned 2003.
-