Commit graph

2937 commits

Author SHA1 Message Date
Sunny Bains
d1809a5c85 Bug #13817703 - auto_increment_offset != 1 + innodb_autoinc_lock_mode=1 => bulk inserts fail
Fix the calculation of the next autoinc value when offset > 1. Some of the
results have changed due to the changes in the allocation calculation. The
new calculation will result in slightly bigger gaps for bulk inserts.
  
rb://866 Approved by Jimmy Yang.
Backported from mysql-trunk (5.6)
2012-03-29 18:02:08 +11:00
Joerg Bruehe
747fbf8f8b Merge the 5.5.22 release build into main 5.5,
conflict in "sql/filesort.cc" solved manually.
2012-03-20 22:27:49 +01:00
Annamalai Gurusami
a2d6f81a02 Merging from mysql-5.1 to mysql-5.5. 2012-03-16 12:10:54 +05:30
Annamalai Gurusami
08f051df04 Bug #11766634 59783: INNODB DATA GROWS UNEXPECTEDLY WHEN INSERTING, TRUNCATING, INSERTING THE
The test case must insert all the records using a single transaction. Otherwise the test 
case takes more than 15 minutes and will time out in pb2 and mtr.
2012-03-16 12:06:29 +05:30
Luis Soares
4977b60e59 BUG#12400313
Automerging from mysql-5.1.
2012-03-12 23:26:00 +00:00
Luis Soares
7f84e70b86 BUG#12400313
Adding missing sync_slave_with_master to the test case.
2012-03-12 23:23:40 +00:00
Luis Soares
66a306e6e2 BUG#12400313
Fixing waiting condition. "enter_cond" text changed in 5.5+ (when the SQL thread
is waiting for more events).
2012-03-12 23:21:03 +00:00
Luis Soares
9794750125 BUG#12400313
Automerge changes to the test case from mysql-5.1.
2012-03-12 23:18:24 +00:00
Luis Soares
a68e3d26b9 Automerge merge with latest mysql-5.1. 2012-03-12 23:16:44 +00:00
Luis Soares
9eedf9b452 BUG#12400313
Hardening the test case:
  - including a diff_tables at the end.
  - increasing the tolerance on the relay limit size.
2012-03-12 23:15:01 +00:00
Luis Soares
549a5fa249 BUG#12400313
Manual merge from mysql-5.1 into mysql-5.5.

CONFLICTS
=========
  Text conflict in sql/log.cc
  Text conflict in sql/slave.cc
2012-03-12 22:02:50 +00:00
Luis Soares
28e7195644 BUG#12400313
Automerge with mysql-5.1.
2012-03-12 21:58:00 +00:00
Luis Soares
4a6c4d8603 BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES
BUG#64503: mysql frequently ignores --relay-log-space-limit

When the SQL thread goes to sleep, waiting for more events, it sets
the flag ignore_log_space_limit to true. This gives the IO thread a
chance to queue some more events and ultimately the SQL thread will be
able to purge the log once it is rotated. By then the SQL thread
resets the ignore_log_space_limit to false. However, between the time
the SQL thread has set the ignore flag and the time it resets it, the
IO thread will be queuing events in the relay log, possibly going way
over the limit.

This patch makes the IO and SQL thread to synchronize when they reach
the space limit and only ask for one event at a time. Thus the SQL
thread sets ignore_log_space_limit flag and the IO thread resets it to
false everytime it processes one more event. In addition, everytime
the SQL thread processes the next event, and the limit has been
reached, it checks if the IO thread should rotate. If it should, it
instructs the IO thread to rotate, giving the SQL thread a chance to
purge the logs (freeing space). Finally, this patch removes the
resetting of the ignore_log_space_limit flag from purge_first_log,
because this is now reset by the IO thread every time it processes the
next event when the limit has been reached.

If the SQL thread is in a transaction, it cannot purge so, there is no
point in asking the IO thread to rotate. The only thing it can do is
to ask for more events until the transaction is over (then it can ask
the IO to rotate and purge the log right away). Otherwise, there would
be a deadlock (SQL would not be able to purge and IO thread would not
be able to queue events so that the SQL would finish the transaction).
2012-03-12 12:28:27 +00:00
Annamalai Gurusami
29aaa6588d Bug #11766634 59783: InnoDB data grows unexpectedly when inserting,
truncating, inserting the same set of rows. When a table is 
re-created with the same set of rows, the data file size must
not grow.  

rb:968
Approved by Marko.
2012-03-09 11:07:16 +05:30
Manish Kumar
a54e6e002d BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2
Fix - Changed the implementation of the condition check from the result file
      to using an assert.

mysql-test/suite/rpl/r/rpl_report_port.result:
  Updated the result file.
mysql-test/suite/rpl/t/rpl_report_port.test:
  Changed from the a condtional check to an assert.
2012-03-09 08:07:16 +05:30
Annamalai Gurusami
3ce20ed4f9 Merging from mysql-5.1 to mysql-5.5. 2012-03-09 12:35:27 +05:30
Marko Mäkelä
4c74d96f51 Remove a duplicate mysql-test file innodb-index.inc. 2012-03-06 13:31:18 +02:00
Praveenkumar Hulakund
c22c9270fb Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
Analysis:
========================
sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
instead of escape character in a string literal then sql_mode can be set to 
"NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
character like any other. 

SQL_MODE set applies to the current client session. And while creating the stored 
procedure, MySQL stores the current sql_mode and always executes the stored 
procedure in sql_mode stored with the Procedure, regardless of the server SQL 
mode in effect when the routine is invoked.  

In the scenario (for which bug is reported), the routine is created with 
sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
is "" (NOT SET) by executing statement "call testp('Axel\'s')".
Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
is considered as escape character and column "a" (of table "t1") values are 
updated with "Axel's". The binary log generated for above update operation is as below,

  set sql_mode=XXXXXX (for no_backslash_escapes)
  update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');

While logging stored procedure statements, the local variables (params) used in
statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
(http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)

On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
is also logged in. So that at slave this sql_mode is set before executing the statements
of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
and parsing reported error for "'" (as we have only one "'" no backslash). 

At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
But above error reported while writing bin log, "'" (of Axel's) is escaped with
"\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
while writing NAME_CONST for string variable(param, local variable) in bin log 
Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
that logging string parameter does not take into account sql_mode value.

Fix:
========================
So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
(n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
escape such characters while writing NAME_CONST for string variables in bin 
log. 
And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
represented as ''.
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
ways to include quote characters within a string: )



mysql-test/r/sql_mode.result:
  Added test case for Bug#12601974.
mysql-test/suite/binlog/r/binlog_sql_mode.result:
  Appended result of test cases added for Bug#12601974.
mysql-test/suite/binlog/t/binlog_sql_mode.test:
  Added test case for Bug#12601974.
mysql-test/t/sql_mode.test:
  Appended result of test cases added for Bug#12601974.
2012-02-29 12:23:15 +05:30
Praveenkumar Hulakund
a0b46059ee Merge from 5.1 to 5.5 2012-02-29 14:15:15 +05:30
Manish Kumar
9e048a6bc5 BUG#13333431 - INCORRECT DEFAULT PORT IN 'SHOW SLAVE HOSTS' OUTPUT
Problem - The default port number shown in SHOW SLAVE HOSTS is always 3306 
          though the slave is actually listening on a different port number.
          This is a problem as the user can not be sure whether this port 
          value can be trusted and so client trying to read replication 
          topology can get confused.

Fix - 3306 ceases to be the default value of report-port. Moreover report-port
      does not have a static default any longer.
      Instead we initialize report-port to 0 as the new default value and change
      it based on two checks :

      1) If report_port is not set, the slave reports the port number its listening 
         on. (i.e. if report-port is not set we get the actual value of the slave's 
         port number).

      2) If report-port is set, we show the value report-port is set to, as the slave's
         port number.

mysql-test/include/show_slave_hosts.inc:
  A .inc file is added to use show slave hosts in the new test added.
mysql-test/r/mysqld--help-notwin.result:
  Updated the result file to show the default value passed for report-port.
mysql-test/suite/rpl/r/rpl_report_port.result:
  The result file for the new test that is added.
mysql-test/suite/rpl/r/rpl_show_slave_hosts.result:
  Updated the result file to show the default value passed for report-port.
mysql-test/suite/rpl/t/rpl_report_port-slave.opt:
  Option file for the new test added.
mysql-test/suite/rpl/t/rpl_report_port.test:
  Added a test to check the correct functionality of report-port. 
  We check this by running the replication twice. 
          
  In the first run we do not set the value of report-port through the opt file 
  and get the actual port number of the slave's port.
          
  We then restart the server with report-port set to some value (in this case 9000)
  and check the value reported for the slave's port number.
mysql-test/suite/sys_vars/t/report_port_basic.test:
  Update the test file to show the value for report-port. It is replaced with
  SLAVE_PORT as the actual value of the report-port will change with each run.
sql/mysqld.cc:
  Changed the value reported by report port :
          
  1. If the value for report-port is not set we assign report-port to be the 
     actual port number of the slave (mysqld_port).
  
  2. If report-port is set we get the value set for the report-port.
sql/sys_vars.cc:
  Passed 0 as the default value of the report-port.
2012-02-28 14:02:27 +05:30
Vasil Dimov
c538ba96cd Merge mysql-5.1 -> mysql-5.5 2012-02-21 18:20:12 +02:00
Vasil Dimov
c2d0fea84e Fix Bug#13639142 64128: INNODB ERROR IN SERVER LOG OF INNODB_BUG34300
Suppress innodb_bug34300 from failing if InnoDB prints:

  120221 11:05:03  InnoDB: ERROR: the age of the last checkpoint is 9439048,
  InnoDB: which exceeds the log group capacity 9433498.

by default the log capacity is 2 log files, 5 MB each.
2012-02-21 17:57:07 +02:00
Georgi Kodinov
d4c35861e5 merge mysql-5.5->mysql-5.5-security 2012-02-18 10:58:31 +02:00
Georgi Kodinov
9f18fc5a06 merged mysql-5.5->mysql-5.5-security 2012-02-17 11:55:36 +02:00
Marko Mäkelä
4ea57c80b2 Merge mysql-5.1 to mysql-5.5. 2012-02-17 11:52:51 +02:00
Marko Mäkelä
f77329ace9 Bug#13721257 RACE CONDITION IN UPDATES OR INSERTS OF WIDE RECORDS
This bug was originally filed and fixed as Bug#12612184. The original
fix was buggy, and it was patched by Bug#12704861. Also that patch was
buggy (potentially breaking crash recovery), and both fixes were
reverted.

This fix was not ported to the built-in InnoDB of MySQL 5.1, because
the function signatures of many core functions are different from
InnoDB Plugin and later versions. The block allocation routines and
their callers would have to changed so that they handle block
descriptors instead of page frames.

When a record is updated so that its size grows, non-updated columns
can be selected for external (off-page) storage. The bug is that the
initially inserted updated record contains an all-zero BLOB pointer to
the field that was not updated. Only after the BLOB pages have been
allocated and written, the valid pointer can be written to the record.

Between the release of the page latch in mtr_commit(mtr) after
btr_cur_pessimistic_update() and the re-latching of the page in
btr_pcur_restore_position(), other threads can see the invalid BLOB
pointer consisting of 20 zero bytes. Moreover, if the system crashes
at this point, the situation could persist after crash recovery, and
the contents of the non-updated column would be permanently lost.

The problem is amplified by the ROW_FORMAT=DYNAMIC and
ROW_FORMAT=COMPRESSED that were introduced in
innodb_file_format=barracuda in InnoDB Plugin, but the bug does exist
in all InnoDB versions.

The fix is as follows. After a pessimistic B-tree operation that needs
to write out off-page columns, allocate the pages for these columns in
the mini-transaction that performed the B-tree operation (btr_mtr),
but write the pages in a separate mini-transaction (blob_mtr). Do
mtr_commit(blob_mtr) before mtr_commit(btr_mtr). A quirk: Do not reuse
pages that were previously freed in btr_mtr. Only write the off-page
columns to 'fresh' pages.

In this way, crash recovery will see redo log entries for blob_mtr
before any redo log entry for btr_mtr. It will apply the BLOB page
writes to pages that were marked free at that point. If crash recovery
fails to see all of the btr_mtr redo log, there will be some
unreachable BLOB data in free pages, but the B-tree will be in a
consistent state.

btr_page_alloc_low(): Renamed from btr_page_alloc(). Add the parameter
init_mtr. Return an allocated block, or NULL. If init_mtr!=mtr but
the page was already X-latched in mtr, do not initialize the page.

btr_page_alloc(): Wrapper for btr_page_alloc_for_ibuf() and
btr_page_alloc_low().

btr_page_free(): Add a debug assertion that the page was a B-tree page.

btr_lift_page_up(): Return the father block.

btr_compress(), btr_cur_compress_if_useful(): Add the parameter ibool
adjust, for adjusting the cursor position.

btr_cur_pessimistic_update(): Preserve the cursor position when
big_rec will be written and the new flag BTR_KEEP_POS_FLAG is defined.
Remove a duplicate rec_get_offsets() call. Keep the X-latch on
index->lock when big_rec is needed.

btr_store_big_rec_extern_fields(): Replace update_inplace with
an operation code, and local_mtr with btr_mtr. When not doing a
fresh insert and btr_mtr has freed pages, put aside any pages that
were previously X-latched in btr_mtr, and free the pages after
writing out all data. The data must be written to 'fresh' pages,
because btr_mtr will be committed and written to the redo log after
the BLOB writes have been written to the redo log.

btr_blob_op_is_update(): Check if an operation passed to
btr_store_big_rec_extern_fields() is an update or insert-by-update.

fseg_alloc_free_page_low(), fsp_alloc_free_page(),
fseg_alloc_free_extent(), fseg_alloc_free_page_general(): Add the
parameter init_mtr. Return an allocated block, or NULL. If
init_mtr!=mtr but the page was already X-latched in mtr, do not
initialize the page.

xdes_get_descriptor_with_space_hdr(): Assert that the file space
header is being X-latched.

fsp_alloc_from_free_frag(): Refactored from fsp_alloc_free_page().

fsp_page_create(): New function, for allocating, X-latching and
potentially initializing a page. If init_mtr!=mtr but the page was
already X-latched in mtr, do not initialize the page.

fsp_free_page(): Add ut_ad(0) to the error outcomes.

fsp_free_page(), fseg_free_page_low(): Increment mtr->n_freed_pages.

fsp_alloc_seg_inode_page(), fseg_create_general(): Assert that the
page was not previously X-latched in the mini-transaction. A file
segment or inode page should never be allocated in the middle of an
mini-transaction that frees pages, such as btr_cur_pessimistic_delete().

fseg_alloc_free_page_low(): If the hinted page was allocated, skip the
check if the tablespace should be extended. Return NULL instead of
FIL_NULL on failure. Remove the flag frag_page_allocated. Instead,
return directly, because the page would already have been initialized.

fseg_find_free_frag_page_slot() would return ULINT_UNDEFINED on error,
not FIL_NULL. Correct a bogus assertion.

fseg_alloc_free_page(): Redefine as a wrapper macro around
fseg_alloc_free_page_general().

buf_block_buf_fix_inc(): Move the definition from the buf0buf.ic to
buf0buf.h, so that it can be called from other modules.

mtr_t: Add n_freed_pages (number of pages that have been freed).

page_rec_get_nth_const(), page_rec_get_nth(): The inverse function of
page_rec_get_n_recs_before(), get the nth record of the record
list. This is faster than iterating the linked list. Refactored from
page_get_middle_rec().

trx_undo_rec_copy(): Add a debug assertion for the length.

trx_undo_add_page(): Return a block descriptor or NULL instead of a
page number or FIL_NULL.

trx_undo_report_row_operation(): Add debug assertions.

trx_sys_create_doublewrite_buf(): Assert that each page was not
previously X-latched.

page_cur_insert_rec_zip_reorg(): Make use of page_rec_get_nth().

row_ins_clust_index_entry_by_modify(): Pass BTR_KEEP_POS_FLAG, so that
the repositioning of the cursor can be avoided.

row_ins_index_entry_low(): Add DEBUG_SYNC points before and after
writing off-page columns. If inserting by updating a delete-marked
record, do not reposition the cursor or commit the mini-transaction
before writing the off-page columns.

row_build(): Tighten a debug assertion about null BLOB pointers.

row_upd_clust_rec(): Add DEBUG_SYNC points before and after writing
off-page columns. Do not reposition the cursor or commit the
mini-transaction before writing the off-page columns.

rb:939 approved by Jimmy Yang
2012-02-17 11:42:04 +02:00
Marko Mäkelä
ee9359840f Merge mysql-5.1 to mysql-5.5. 2012-02-15 16:37:06 +02:00
Marko Mäkelä
2a6a6abb70 Remove a race condition in innodb_bug53756.test.
Before killing the server, tell mysql-test-run that it is to be expected.

Discussed with Bjorn Munch on IM.
2012-02-15 16:28:00 +02:00
Rohit Kalhans
701cef2d35 BUG#11758263: Modification of indentation in the added code.
Fixed a typo in the comment.
              Fixing test cases which were previouslyno throwing  due
              disable warnings macro. 

sql/sql_base.cc:
  Change in indentation and fixing a typo in the comment.
2012-02-13 14:12:13 +05:30
Rohit Kalhans
31c990ca57 BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE
Problem: Statements that write to tables with auto_increment columns
         based on the selection from another table, may lead to master
         and slave going out of sync, as the order in which the rows
         are retrieved from the table may differ on master and slave.
            
Solution: We mark writing to a table with auto_increment table
          based on the rows selected from another table as unsafe. This
          will cause the execution of such statements to throw a warning
          and forces the statement to be logged in ROW if the logging
          format is mixed. 
            
Changes:
       1. All the statements that writes to a table with auto_increment 
          column(s) based on the rows fetched from another table, will now
          be unsafe.
       2. CREATE TABLE with SELECT will now be unsafe.

sql/share/errmsg-utf8.txt:
  Added new warning messages.
sql/sql_base.cc:
  -Created function to check statements that write to 
   tables with auto_increment column and has select.
  -Marked all the statements that write to a table
   with auto_increment column based on rows fetched
   from other table(s) as unsafe.
sql/sql_table.cc:
  mark CREATE TABLE[with auto_increment column] as unsafe.
2012-02-09 23:28:33 +05:30
Rohit Kalhans
b7430d73e4 Backout the patch for bug#11758263. 2012-02-08 12:10:55 +05:30
Rohit Kalhans
de85a60049 BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE
Problem: Statements that write to tables with auto_increment columns
      based on the selection from another table, may lead to master
      and slave going out of sync, as the order in which the rows
      are retrived from the table may differ on master and slave.
      
      Solution: We mark writing to a table with auto_increment table
      as unsafe. This will cause the execution of such statements to
      throw a warning and forces the statement to be logged in ROW if
      the logging format is mixed. 
      
      Changes: 
      1. All the statements that writes to a table with auto_increment 
      column(s) based on the rows fetched from another table, will now
      be unsafe.
      2. CREATE TABLE with SELECT will now be unsafe.


sql/share/errmsg-utf8.txt:
  Added new Warning messages
sql/sql_base.cc:
  created a new function that checks for select + write on a autoinc table
  made all such statements to be unsafe.
sql/sql_parse.cc:
  made create autoincremnet tabble + select unsafe
2012-02-08 00:33:08 +05:30
Georgi Kodinov
91c1c93019 merge mysql-5.5->mysql-5.5-security 2012-02-06 18:26:36 +02:00
Vasil Dimov
56e3f68c72 Merge mysql-5.1 -> mysql-5.5
The actual Bug#11754376 does not exist in MySQL 5.5 because at startup
we drop entries for temporary tables from InnoDB dictionary cache (only
if ROW_FORMAT is not REDUNDANT). But nevertheless the bug in
normalize_table_name_low() is present so we fix it.
2012-02-06 13:00:41 +02:00
Vasil Dimov
1c4fd3bb54 Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON
GRACEFUL SHUTDOWN

During startup mysql picks up .frm files from the tmpdir directory and
tries to drop those tables in the storage engine.

The problem is that when tmpdir ends in / then ha_innobase::delete_table()
is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
to delete the table entry from the InnoDB dictionary cache.
ha_innobase::delete_table() returns an error but nevertheless mysql wipes
away the .frm file and the entry in the InnoDB dictionary cache remains
orphaned with no easy way to remove it.

The "no easy" way to remove it is to create a similar temporary table again,
copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
after restart and will try to issue drop table for "/var/tmp/#sql123"
(notice do double slash), ha_innobase::delete_table() will normalize it to
"tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
table entry from the dictionary cache.

The solution is to fix normalize_table_name_low() to normalize things like
"/var/tmp//table" correctly to "tmp/table".

This patch also adds a test function which invokes
normalize_table_name_low() with various inputs to make sure it works
correctly and a mtr test that calls this test function.

Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)
2012-02-06 12:44:59 +02:00
Alexander Barkov
e6ce99e692 Merging from 5.1 2012-02-02 16:25:48 +04:00
Alexander Barkov
bbcc86f5d4 Postfix for Bug#11752408.
Recording correct test results.

modified:
  mysql-test/suite/engines/funcs/r/db_alter_collate_ascii.result
  mysql-test/suite/engines/funcs/r/db_alter_collate_utf8.result
2012-02-02 16:22:13 +04:00
Marko Mäkelä
567a422cf9 Merge mysql-5.1 to mysql-5.5. 2012-02-02 13:50:54 +02:00
Marko Mäkelä
e726580b66 Bug#13654923 BOGUS DEBUG ASSERTION IN INDEX CREATION FOR ZERO-LENGTH RECORD
row_merge_buf_write(): Relax the bogus assertion.
2012-02-02 13:38:32 +02:00
Marko Mäkelä
99ce943014 Merge mysql-5.1 to mysql-5.5. 2012-02-02 12:13:35 +02:00
Marko Mäkelä
ed822984e1 Suppress messages about long semaphore waits in innodb_bug34300.test. 2012-02-02 12:07:06 +02:00
Andrei Elkin
f0167f8082 merge from 5.5 repo. 2012-01-31 17:07:44 +02:00
Nuno Carvalho
dfd38fb5f6 BUG#12403008 RPL_HEARTBEAT_BASIC FAILS SPORADICALLY ON PUSHBUILD
rpl_heartbeat_basic test fails sporadically on pushbuild because did
not received all heartbeats from slave in circular replication.

MASTER_HEARTBEAT_PERIOD had the default value (slave_net_timeout/2) so
wait on "Heartbeat event received on master", that only waits for 1
minute, sometimes timeout before heartbeat arrives. Fixed setting a
smaller period value.
2012-01-25 18:05:10 +00:00
Dmitry Shulga
97883d3c04 Fixed bug#11753187 (formerly known as bug 44585): SP_CACHE BEHAVES AS
MEMORY LEAK.

Background:
 - There are caches for stored functions and stored procedures (SP-cache);
 - There is no similar cache for events;
 - Triggers are cached together with TABLE objects;
 - Those SP-caches are per-session (i.e. specific to each session);
 - A stored routine is represented by a sp_head-instance internally;
 - SP-cache basically contains sp_head-objects of stored routines, which
   have been executed in a session;
 - sp_head-object is added into the SP-cache before the corresponding
   stored routine is executed;
 - SP-cache is flushed in the end of the session.

The problem was that SP-cache might grow without any limit. Although this
was not a pure memory leak (the SP-cache is flushed when session is closed),
this is still a problem, because the user might take much memory by
executing many stored routines.

The patch fixes this problem in the least-intrusive way. A soft limit
(similar to the size of table definition cache) is introduced. To represent
such limit the new runtime configuration parameter 'stored_program_cache'
is introduced. The value of this parameter is stored in the new global
variable stored_program_cache_size that used to control the size of SP-cache
to overflow. 

The parameter 'stored_program_cache' limits number of cached routines for
each thread. It has the following min/default/max values given from support:
  min = 256, default = 256, max = 512 * 1024.
Also it should be noted that this parameter limits the size of 
each cache (for stored procedures and for stored functions) separately.

The SP-cache size is checked after top-level statement is parsed.
If SP-cache size exceeds the limit specified by parameter
'stored_program_cache' then SP-cache is flushed and memory allocated for
cache objects is freed. Such approach allows to flush cache safely 
when there are dependencies among stored routines.


sql/mysqld.cc:
  Added global variable stored_program_cache_size to store value of
  configuration parameter 'stored-program-cache'.
sql/mysqld.h:
  Added declaration of global variable stored_program_cache_size.
sql/sp_cache.cc:
  Extended interface for sp_cache by adding helper routine
  sp_cache_enforce_limit to control size of stored routines cache for
  overflow. Also added method enforce_limit into class sp_cache that
  implements control of cache size for overflow.
sql/sp_cache.h:
  Extended interface for sp_cache by adding standalone routine
  sp_cache_enforce_limit to control size of stored routines cache
  for overflow.
sql/sql_parse.cc:
  Added flush of sp_cache after processing of next sql-statement
  received from a client.
sql/sql_prepare.cc:
  Added flush of sp_cache after preparation/execution of next prepared
  sql-statement received from a client.
sql/sys_vars.cc:
  Added support for configuration parameter stored-program-cache.
2012-01-25 15:59:30 +06:00
Manish Kumar
e69da6dc3e BUG#11752315 - 43460: STOP SLAVE UNABLE TO COMPLETE WHEN SLAVE THREAD IS TRYING TO RECONNECT TO
Problem : The basic problem is the way the thread sleeps in mysql-5.5 and also in mysql-5.1
          when we execute a stop slave on windows platform.
          On windows platform if the stop slave is executed after the master dies, we have 
          this long wait before the stop slave return a value. This is because there is a 
          sleep of the thread. The sleep is uninterruptable in the two above version,
          which was fixed by Davi patch for the BUG#11765860 for mysql-trunk. Backporting 
          his patch for mysql-5.5 fixes the problem. 

Solution : A new pair of mutex and condition variable is introduced to synchronize thread 
           sleep and finalization. A new mutex is required because the slave threads are 
           terminated while holding the slave thread locks (run_lock), which can not be 
           relinquished during termination as this would affect the lock order.

mysql-test/suite/rpl/r/rpl_start_stop_slave.result:
  The result file associated with the test added.
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
  A test to check the new functionality.
sql/rpl_mi.cc:
  The constructor using the new mutex and condition variables for the master_info.
sql/rpl_mi.h:
  The condition variable and mutex have been added for the master_info.
sql/rpl_rli.cc:
  The constructor using the new mutex and condition variables for the realy_log_info.
sql/rpl_rli.h:
  The condition variable and mutex have been added for the relay_log_info.
sql/slave.cc:
  Use a timed wait on a condition variable to implement a interruptible sleep. 
  The wait is registered with the THD object so that the thread will be woken 
  up if killed.
2012-01-23 17:39:37 +05:30
Nuno Carvalho
37fce0ece4 BUG#13050593 - BACKSLASH SWALLOWED BY INCLUDE/SHOW_SLAVE_STATUS.INC
If an error message contains '\' backslash it is displayed correctly
through show-slave-status or
query_get_value(SHOW SLAVE STATUS, Last_IO_Error, 1);. But when
SELECT REPLACE(...) is applied backslash is escaped resulting in a
different test output.

Disabled backslash escape on show_slave_status.inc and replaced '\' for
'/' using replace_regex function in order to achieve the same test
output when different path separators are used.
2012-01-19 16:56:43 +00:00
Andrei Elkin
f91c2d33f4 bug#3593869-64035
A follow-up patch corrects max sizes of printed strings and changes llstr() to %lld.
Credits go to Davi who provided a great feedback.


sql/share/errmsg-utf8.txt:
  Max size for the whole message is 512 so a part of - like '%-.512s' should be less,
  reduction to 320 is safe and with good chances won't cut off a part of a rather log
  message in Last_IO_Error = 'Got fatal error 1236 ...'
sql/sql_repl.cc:
  llstr() is replaced by %lld.
2012-01-19 16:44:09 +02:00
Andrei Elkin
8c894564ab merging from the 5.5 repo to local branch. 2012-01-18 00:35:53 +02:00
Andrei Elkin
7cdd7a7493 BUG#13593869 - 64035: SEVERAL ERRORS IN COM_BINLOG_DUMP/MYSQL_BINLOG_SEND CRASH THE SERVER
The server crashes when receiving a COM_BINLOG_DUMP command with a position of 0 or
larger than the file size.
The execution proceeds to an error block having the last read replication coordinates 
pointer be NULL and its dereferencing crashed the server.

Fixed with making "public" previously used only for heartbeat coordinates.


mysql-test/extra/rpl_tests/rpl_start_stop_slave.test:
  regression test for bug#3593869-64035 is added.
mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result:
  results updated (error mess format is changed).
mysql-test/suite/rpl/r/rpl_log_pos.result:
  results updated (error mess format is changed).
mysql-test/suite/rpl/r/rpl_manual_change_index_file.result:
  results updated (error mess format is changed).
mysql-test/suite/rpl/r/rpl_packet.result:
  results updated (error mess format is changed).
mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result:
  results updated (error mess format is changed).
mysql-test/suite/rpl/t/rpl_stm_start_stop_slave.test:
  Slave is stopped by bug#3593869-64035 tests so 
  -let $rpl_only_running_threads= 1 is set prior to rpl_end.
sql/share/errmsg-utf8.txt:
  Increasing the max length of explanatory message to 512.
sql/sql_repl.cc:
  Making `coord' to carry the last read from binlog event coordinates
  regardless of heartbeat.
  Renaming, small cleanup and simplifying the code after if (coord) becomes unnecessary.
  Adding yet another 3rd pair of coordinates - the starting replication - 
  into error text.
2012-01-18 00:16:19 +02:00
Georgi Kodinov
a72f7ee6a3 merged bug #11754014 2012-01-17 11:38:34 +02:00