Commit graph

26215 commits

Author SHA1 Message Date
Dmitry Shulga
bc7af17579 Fixed Bug#11756013 (formerly known as bug#47870):
BOGUS "THE TABLE MYSQL.PROC IS MISSING,..."

There was a race condition between loading a stored routine
(function/procedure/trigger) specified by fully qualified name
SCHEMA_NAME.PROC_NAME and dropping the stored routine database.

The problem was that there is a window for race condition when one server
thread tries to load a stored routine being executed and the other thread
tries to drop the stored routine schema.

This condition race window exists in implementation of function
mysql_change_db() called by db_load_routine() during loading of stored
routine to cache. Function mysql_change_db() calls check_db_dir_existence()
that might failed because specified database was dropped during concurrent
execution of DROP SCHEMA statement. db_load_routine() calls mysql_change_db()
with flag 'force_switch' set to 'true' value so when referenced db is not found
then my_error() is not called and function mysql_change_db() returns ok.
This shadows information about schema opening error in db_load_routine().
Then db_load_routine() makes attempt to parse stored routine that is failed.
This makes to return error to sp_cache_routines_and_add_tables_aux() but since
during error generation a call to my_error wasn't made and hence
THD::main_da wasn't set we set the generic "mysql.proc table corrupt" error
when running sp_cache_routines_and_add_tables_aux().

The fix is to install an error handler inside db_load_routine() for
the mysql_op_change_db() call, and check later if the ER_BAD_DB_ERROR
was caught.


sql/sql_db.cc:
  Added synchronization point "before_db_dir_check" to emulate a race condition during
  processing of CALL/DROP SCHEMA.
2011-06-23 20:41:04 +07:00
Dmitry Lenev
edfd31a06a Fix for bug - "61493: REORDERING COLUMNS
TO POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
 
ALTER TABLE MODIFY/CHANGE ... FIRST did nothing except renaming
columns if new version of the table had exactly the same 
structure as the old one (i.e. as result of such statement, names 
of columns changed their order as specified but data in columns 
didn't). The same thing happened for ALTER TABLE DROP COLUMN/ADD 
COLUMN statements which were supposed to produce new version of
table with exactly the same structure as the old version of table.
I.e. in the latter case the result was the same as if old column 
was renamed instead of being dropped and new column with default
as value being created.
 
Both these problems were caused by the fact that ALTER TABLE
implementation incorrectly interpreted both these situations as 
simple renaming of columns and assumed that in-place ALTER TABLE
algorithm could have been used for them.
 
This patch fixes this problem by ensuring that in cases when some
column is moved to the first position or some column is dropped
the default ALTER TABLE algorithm involving table copying is 
always used. This is achieved by detecting such situations in
mysql_prepare_alter_table() and setting Alter_info::change_level
to ALTER_TABLE_DATA_CHANGED for them.

mysql-test/r/alter_table.result:
  Added test for bug  - "61493: REORDERING COLUMNS TO
  POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
mysql-test/t/alter_table.test:
  Added test for bug  - "61493: REORDERING COLUMNS TO
  POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
sql/sql_table.cc:
  Changed mysql_prepare_alter_table() to detect situations in 
  which we some column moved to the first position or some column 
  is dropped and ensure that such ALTER TABLE statements won't
  be carried out using in-place algorithm. The latter could have 
  happened before this patch if new version of table had the same 
  structure as the old one (except the column names).
2011-06-17 02:02:52 +04:00
Mattias Jonsson
44aa582bb3 merge 2011-06-13 11:09:56 +02:00
Dmitry Shulga
1fea8c1b90 Fixed bug#11753738 (formely known as bug#45235) - 5.1 DOES NOT SUPPORT 5.0-ONLY
SYNTAX TRIGGERS IN ANY WAY

Table with triggers which were using deprecated (5.0-only) syntax became
unavailable for any DML and DDL after upgrade to 5.1 version of server.
Attempt to execute any statement on such a table resulted in parsing
error reported. Since this included DROP TRIGGER and DROP TABLE
statements (actually, the latter was allowed but was not functioning
properly for such tables) it was impossible to fix the problem without
manual operations on .TRG and .TRN files in data directory.

The problem was that failure to parse trigger body (due to 5.0-only
syntax) when opening trigger file for a table prevented the table
from being open. This made all operations on the table impossible
(except DROP TABLE which due to peculiarity in its implementation
dropped the table but left trigger files around).

This patch solves this problem by silencing error which occurs when
we parse trigger body during table open. Error message is preserved
for the future use and table is marked as having a broken trigger.
We also try to analyze parse tree to recover trigger name, which
will be needed in order to drop the broken trigger. DML statements
which invoke triggers on the table marked as having broken trigger
are prohibited and emit saved error message. The same happens for
DDL which change triggers except DROP TRIGGER and DROP TABLE which
try their best to do what was requested. Table becomes no longer
marked as having broken trigger when last such trigger is dropped.

mysql-test/r/trigger-compat.result:
  Add results for test case for bug#45235
mysql-test/t/trigger-compat.test:
  Add test case for bug#45235.
sql/sp_head.cc:
  Added protection against MEM_ROOT double restoring to
  sp_head::restore_thd_mem_root() method. Since this
  method can be sometimes called twice during parsing
  of stored routine (the first time during normal flow
  of parsing, and the second time when a syntax error
  is detected) we need to shortcut execution of the
  method to avoid damaging MEM_ROOT by the second
  consecutive call to this method.
sql/sql_trigger.cc:
  Added error handler Deprecated_trigger_syntax_handler to 
  catch non-OOM errors during parsing of trigger body.
  
  Added handling of parse errors into method 
  Table_triggers_list::check_n_load().
sql/sql_trigger.h:
  Added new members to handle broken triggers and error messages.
2011-06-10 10:52:39 +07:00
Dmitry Shulga
53e4a85204 Follow-up for patch of bug#11764334. 2011-06-10 01:05:10 +07:00
Dmitry Shulga
fa913a0b98 Fixed bug#11764334 (formerly bug#57156): ALTER EVENT CHANGES
THE EVENT STATUS.

Any ALTER EVENT statement on a disabled event enabled it back
(unless this ALTER EVENT statement explicitly disabled the event).

The problem was that during processing of an ALTER EVENT statement
value of status field was overwritten unconditionally even if new
value was not specified explicitly. As a consequence this field
was set to default value for status which corresponds to ENABLE.

The solution is to check if status field was explicitly specified in
ALTER EVENT statement before assigning new value to status field.

mysql-test/r/events_bugs.result:
  test's result for Bug#11764334 was added.
mysql-test/t/events_bugs.test:
  new test for Bug#11764334 was added.
sql/event_db_repository.cc:
  mysql_event_fill_row() was modified: set value for status field
  in events tables only in case if statement CREATE EVENT
  is being processed or if this value was set in ALTER EVENT
  statement.
  Event_db_repository::create_event was modified: removed redundant
  setting of status field after return from call to mysql_event_fill_row().
sql/event_parse_data.h:
  Event_parse_data structure was modified: added flag
  status_changed that is set to true if status's value
  was changed in ALTER EVENT statement.
sql/sql_yacc.yy:
  Set flag status_changed if status was set in ALTER EVENT
  statement.
2011-06-10 00:03:17 +07:00
Ramil Kalimullin
768b9a0ef6 Bug#11764487: myisam corruption with insert ignore and invalid spatial data
Problem: in case of wrong data insert into indexed GEOMETRY fields 
(e.g. NULL value for a not NULL field) MyISAM reported 
"ERROR 126 (HY000): Incorrect key file for table; try to repair it"
due to misuse of the key deletion function.

Fix: always use R-tree key functions for R-tree based indexes
and B-tree key functions for B-tree based indexes.


mysql-test/r/gis-rtree.result:
  Bug#11764487: myisam corruption with insert ignore and invalid spatial data
    - test result.
mysql-test/t/gis-rtree.test:
  Bug#11764487: myisam corruption with insert ignore and invalid spatial data
    - test case.
storage/myisam/mi_update.c:
  Bug#11764487: myisam corruption with insert ignore and invalid spatial data
    - handling update errors check for HA_ERR_NULL_IN_SPATIAL as well to be 
  consistent with mi_write();
    - always use keyinfo->ck_delete()/ck_insert() instead of _mi_ck_delete()/_mi_ck_write()
  to handle index properly, as it may be of B-tree or R-tree type.
storage/myisam/mi_write.c:
  Bug#11764487: myisam corruption with insert ignore and invalid spatial data
    - always use keyinfo->ck_delete() instead of _mi_ck_delete() to handle
  index properly, as it may be of B-tree or R-tree type.
2011-06-07 19:30:43 +04:00
Georgi Kodinov
b502a64bba Bug : 38965: TEST CASES GIS-RTREE, TYPE_FLOAT, TYPE_NEWDECIMAL
FAIL IN EMBEDDED SERVER

FreeBSD 64 bit needs the FP_X_DNML to fpsetmask() to prevent exceptions from
propagating into mysql (as a threaded application).
However fpsetmask() itself is deprecated in favor of fedisableexcept().
1. Fixed the #ifdef to check for FP_X_DNML instead of i386.
2. Added a configure.in check for fedisableexcept() and, if present,
   this function is called insted of the fpsetmask().
No need for new tests, as the existing tests cover this already.
Removed the affected tests from the experimental list.
2011-06-06 13:13:54 +03:00
Anitha Gopi
6444fa5327 Bug#11756699 : Move test to disabled group 2011-06-03 14:13:10 +05:30
Sergey Vojtovich
2ab0abd268 Merge. 2011-06-03 11:31:13 +04:00
Dmitry Shulga
56a735b782 Fixed bug#12546938 (formerly known as 61005) - CREATE IF NOT EXIST EVENT
will create multiple running events.

A CREATE IF NOT EXIST on an event that existed and was enabled caused
multiple instances of the event to run. Disabling the event didn't  help.
If the event was  dropped, the event stopped running, but when created
again, multiple instances of the event were still running. The only way
to get out of this situation was  to restart the server.

The problem was that Event_db_repository::create_event() didn't return
enough information to discriminate between situation when event didn't
exist and was created and when event did exist and was not created
(but a warning was emitted). As result in the latter case event
was added to in-memory queue of events second time. And this led to
unwarranted multiple executions of the same event.

The solution is to add out-parameter to Event_db_repository::create_event()
method which will signal that event was not created because it already
exists and so it should not be added to the in-memory queue.


mysql-test/r/events_bugs.result:
  Added results for test for Bug#12546938.
mysql-test/t/events_bugs.test:
  Added test for Bug#12546938.
sql/event_db_repository.cc:
  Event_db_repository::create_event was modified: set newly added out-parameter
  event_already_exists to true value if event wasn't created because event
  already existed and IF NOT EXIST clause was present.
sql/event_db_repository.h:
  Added out-parameter 'event_already_exists' to create_event() method.
sql/events.cc:
  Events::create_event was modified: insert new element into
  event queue only if event was actually created.
2011-05-27 16:23:08 +07:00
Dmitry Lenev
861291f1ab Fix for bug - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The 
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock 
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a 
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will 
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ... 
   READ.

Unfortunately both of these approaches have drawbacks which make 
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.1 version of this patch switch from read lock to write
lock is done inside of InnoDBs handler methods as doing it on 
SQL-layer causes compatibility troubles with FLUSH TABLES WITH
READ LOCK.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test for bug  - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug  - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  Added test for bug  - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  Added test for bug  - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
storage/innobase/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.
storage/innodb_plugin/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.
2011-05-26 17:14:47 +04:00
Sven Sandberg
de3776819c BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run
Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
The correct order is first LOCK_thread_count and then LOCK_log. This function
does it the other way around. This leads to deadlock when run in parallel
with a thread that takes the two locks in correct order. For example, a thread
that disconnects will take the locks in the correct order.
Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
first LOCK_thread_count and then LOCK_log.


mysql-test/suite/binlog/r/binlog_reset_master.result:
  added result file
mysql-test/suite/binlog/t/binlog_reset_master.test:
  Added test case that demonstrates deadlock because of wrong mutex order.
  The deadlock is between two threads:
   - RESET MASTER acquires mutexes in wrong order.
   - client thread shutdown code acquires mutexes in right order.
  Actually, this test case does not produce deadlock in 5.1, probably
  the client thread shutdown code does not hold both mutexes at the same
  time. However, the bug existed in 5.1 (mutexes are taken in the wrong
  order) so we push the test case to 5.1 too, to prevent future
  regressions.
sql/log.cc:
  Change mutex acquisition to the correct order:
  first LOCK_thread_count, then LOCK_log.
sql/mysqld.cc:
  Add debug code to synchronize test case.
2011-05-26 12:50:43 +02:00
Sergey Glukhov
3efbf30457 Bug#12392636 ASSERTION FAILED: SCALE >= 0 && PRECISION > 0 && SCALE <= PRECISION
Assertion happens due to missing NULL value check in
Item_func_round::fix_length_and_dec() function.
The fix: added NULL value check for second parameter.


mysql-test/r/func_math.result:
  test case
mysql-test/t/func_math.test:
  test case
sql/item_func.cc:
  added NULL value check for second parameter.
2011-05-26 14:06:39 +04:00
Anitha Gopi
cce8a65843 BUG#12371924 # Bug is fixed. Move test out of experimental group 2011-05-24 15:46:14 +05:30
Anitha Gopi
099fbeb93d Changed to Oracle bug numbers 2011-05-24 12:08:13 +05:30
Anitha Gopi
0464f964ad Bug#11756699: Move test from disabled to experimental group 2011-05-24 10:22:00 +05:30
Anitha Gopi
faf747bf52 Bug#12584161 - Moved test from disabled to experimental group 2011-05-24 09:56:24 +05:30
Guilhem Bichot
06115abdf9 merge from latest 5.1 2011-05-21 10:43:54 +02:00
Luis Soares
4f03d60096 BUG#11746302: 25228: RPL_RELAYSPACE.TEST FAILS ON POWERMACG5,
VM-WIN2003-32-A, SLES10-IA64-A 
      
The test case waits for master_pos_wait not to timeout, which
means that the deadlock between SQL and IO threads was 
succesfully and automatically dealt with.
      
However, very rarely, master_pos_wait reports a timeout. This
happens because the time set for master_pos_wait to wait was
too small (6 seconds). On slow test env this could be a 
problem.
      
We fix this by setting the timeout inline with the one used
in sync_slave_with_master (300 seconds). In addition we 
refactored the test case and refined some comments.
2011-05-19 16:45:45 +01:00
Sergey Vojtovich
c5dd72b506 BUG#12402794 - 60976: CRASH, VALGRIND WARNING AND MEMORY
LEAK WITH PARTITIONED ARCHIVE TABLES

CHECK TABLE against archive table, when file descriptors
are exhausted, caused server crash.

Archive didn't handle errors when opening data file for
CHECK TABLE.

mysql-test/r/archive_debug.result:
  A test case for BUG#12402794.
mysql-test/t/archive_debug.test:
  A test case for BUG#12402794.
storage/archive/azio.c:
  A test case for BUG#12402794.
storage/archive/ha_archive.cc:
  Handle init_archive_reader() failure.
2011-05-18 14:01:43 +04:00
Sergey Glukhov
3201f92cb3 Bug#12403504 AFTER FIX FOR : ASSERTION FAILED: DELSUM+(INT) Y/4-TEMP > 0
There are two problems:
1. There is a missing check for 'year' parameter(year can not be greater than 9999) in
   makedate function. fix: added check that year can not be greater than 9999.
2. There is a missing check for zero date in from_days() function.
   fix: added zero date check into Item_func_from_days::get_date()
   function.


mysql-test/r/func_time.result:
  test case
mysql-test/t/func_time.test:
  test case
sql/item_timefunc.cc:
  --added check that year can not be greater than 9999 for makedate() function
  --added zero date check into Item_func_from_days::get_date() function
2011-05-18 10:47:43 +04:00
Guilhem Bichot
12c42b980a Fix for BUG#11755168 '46895: test "outfile_loaddata" fails (reproducible)'.
In sql_class.cc, 'row_count', of type 'ha_rows', was used as last argument for
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD which is
"Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld".
So 'ha_rows' was used as 'long'.
On SPARC32 Solaris builds, 'long' is 4 bytes and 'ha_rows' is 'longlong' i.e. 8 bytes.
So the printf-like code was reading only the first 4 bytes.
Because the CPU is big-endian, 1LL is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
so the first four bytes yield 0. So the warning message had "row 0" instead of
"row 1" in test outfile_loaddata.test:
-Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 1
+Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 0

All error-messaging functions which internally invoke some printf-life function
are potential candidate for such mistakes.
One apparently easy way to catch such mistakes is to use
ATTRIBUTE_FORMAT (from my_attribute.h).
But this works only when call site has both:
a) the format as a string literal
b) the types of arguments.
So:
  func(ER(ER_BLAH), 10);
will silently not be checked, because ER(ER_BLAH) is not known at
compile time (it is known at run-time, and depends on the chosen
language).
And
  func("%s", a va_list argument);
has the same problem, as the *real* type of arguments is not
known at this site at compile time (it's known in some caller).
Moreover,
  func(ER(ER_BLAH));
though possibly correct (if ER(ER_BLAH) has no '%' markers), will not
compile (gcc says "error: format not a string literal and no format
arguments").

Consequences:
1) ATTRIBUTE_FORMAT is here added only to functions which in practice
take "string literal" formats: "my_error_reporter" and "print_admin_msg".
2) it cannot be added to the other functions: my_error(),
push_warning_printf(), Table_check_intact::report_error(),
general_log_print().

To do a one-time check of functions listed in (2), the following
"static code analysis" has been done:
1) replace
  my_error(ER_xxx, arguments for substitution in format)
with the equivalent
  my_printf_error(ER_xxx,ER(ER_xxx), arguments for substitution in
format),
so that we have ER(ER_xxx) and the arguments *in the same call site*
2) add ATTRIBUTE_FORMAT to push_warning_printf(),
Table_check_intact::report_error(), general_log_print()
3) replace ER(xxx) with the hard-coded English text found in
errmsg.txt (like: ER(ER_UNKNOWN_ERROR) is replaced with
"Unknown error"), so that a call site has the format as string literal
4) this way, ATTRIBUTE_FORMAT can effectively do its job
5) compile, fix errors detected by ATTRIBUTE_FORMAT
6) revert steps 1-2-3.
The present patch has no compiler error when submitted again to the
static code analysis above.
It cannot catch all problems though: see Field::set_warning(), in
which a call to push_warning_printf() has a variable error
(thus, not replacable by a string literal); I checked set_warning() calls
by hand though.

See also WL 5883 for one proposal to avoid such bugs from appearing
again in the future.

The issues fixed in the patch are:
a) mismatch in types (like 'int' passed to '%ld')
b) more arguments passed than specified in the format.
This patch resolves mismatches by changing the type/number of arguments,
not by changing error messages of sql/share/errmsg.txt. The latter would be wrong,
per the following old rule: errmsg.txt must be as stable as possible; no insertions
or deletions of messages, no changes of type or number of printf-like format specifiers,
are allowed, as long as the change impacts a message already released in a GA version.
If this rule is not followed:
- Connectors, which use error message numbers, will be confused (by insertions/deletions
of messages)
- using errmsg.sys of MySQL 5.1.n with mysqld of MySQL 5.1.(n+1)
could produce wrong messages or crash; such usage can easily happen if
installing 5.1.(n+1) while /etc/my.cnf still has --language=/path/to/5.1.n/xxx;
or if copying mysqld from 5.1.(n+1) into a 5.1.n installation.
When fixing b), I have verified that the superfluous arguments were not used in the format
in the first 5.1 GA (5.1.30 'bteam@astra04-20081114162938-z8mctjp6st27uobm').
Had they been used, then passing them today, even if the message doesn't use them
anymore, would have been necessary, as explained above.

include/my_getopt.h:
  this function pointer is used only with "string literal" formats, so we can add
  ATTRIBUTE_FORMAT.
mysql-test/collections/default.experimental:
  test should pass now
sql/derror.cc:
  by having a format as string literal, ATTRIBUTE_FORMAT check becomes effective.
sql/events.cc:
  Change justified by the following excerpt from sql/share/errmsg.txt:
  ER_EVENT_SAME_NAME
          eng "Same old and new event name"
  ER_EVENT_SET_VAR_ERROR
          eng "Error during starting/stopping of the scheduler. Error code %u"
sql/field.cc:
  ER_TOO_BIG_SCALE 42000 S1009
          eng "Too big scale %d specified for column '%-.192s'. Maximum is %lu."
  ER_TOO_BIG_PRECISION 42000 S1009
          eng "Too big precision %d specified for column '%-.192s'. Maximum is %lu."
  ER_TOO_BIG_DISPLAYWIDTH 42000 S1009
          eng "Display width out of range for column '%-.192s' (max = %lu)"
sql/ha_ndbcluster.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
  (sizeof() returns size_t)
sql/ha_ndbcluster_binlog.cc:
  Too many arguments for:
  ER_GET_ERRMSG  
          eng "Got error %d '%-.100s' from %s"
  Patch by Jonas Oreland.
sql/ha_partition.cc:
  print_admin_msg() is used only with a literal as format, so ATTRIBUTE_FORMAT
  works.
sql/handler.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
  (sizeof() returns size_t)
sql/item_create.cc:
  ER_TOO_BIG_SCALE 42000 S1009
          eng "Too big scale %d specified for column '%-.192s'. Maximum is %lu."
  ER_TOO_BIG_PRECISION 42000 S1009
          eng "Too big precision %d specified for column '%-.192s'. Maximum is %lu."
  'c_len' and 'c_dec' are char*, passed as %d !! We don't know their value
  (as strtoul() failed), but they are likely big, so we use INT_MAX.
  'len' is ulong.
sql/item_func.cc:
  ER_WARN_DATA_OUT_OF_RANGE 22003 
          eng "Out of range value for column '%s' at row %ld"
  ER_CANT_FIND_UDF  
          eng "Can't load function '%-.192s'"
sql/item_strfunc.cc:
  ER_TOO_BIG_FOR_UNCOMPRESS  
          eng "Uncompressed data size too large; the maximum size is %d (probably, length of uncompressed data was corrupted)"
  max_allowed_packet is ulong.
sql/mysql_priv.h:
  sql_print_message_func is a function _pointer_.
sql/sp_head.cc:
  ER_SP_RECURSION_LIMIT
          eng "Recursive limit %d (as set by the max_sp_recursion_depth variable) was exceeded for routine %.192s"
  max_sp_recursion_depth is ulong
sql/sql_acl.cc:
  ER_PASSWORD_NO_MATCH 42000 
          eng "Can't find any matching row in the user table"
  ER_CANT_CREATE_USER_WITH_GRANT 42000
          eng "You are not allowed to create a user with GRANT"
sql/sql_base.cc:
  ER_NOT_KEYFILE  
          eng "Incorrect key file for table '%-.200s'; try to repair it"
  ER_TOO_MANY_TABLES  
          eng "Too many tables; MySQL can only use %d tables in a join"
  MAX_TABLES is size_t.
sql/sql_binlog.cc:
  ER_UNKNOWN_ERROR  
          eng "Unknown error"
sql/sql_class.cc:
  ER_TRUNCATED_WRONG_VALUE_FOR_FIELD  
          eng "Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld"
  WARN_DATA_TRUNCATED 01000 
          eng "Data truncated for column '%s' at row %ld"
sql/sql_connect.cc:
  ER_HANDSHAKE_ERROR 08S01 
          eng "Bad handshake"
  ER_BAD_HOST_ERROR 08S01 
          eng "Can't get hostname for your address"
sql/sql_insert.cc:
  ER_WRONG_VALUE_COUNT_ON_ROW 21S01 
          eng "Column count doesn't match value count at row %ld"
sql/sql_parse.cc:
  ER_WARN_HOSTNAME_WONT_WORK  
          eng "MySQL is started in --skip-name-resolve mode; you must restart it without this switch for this grant to work"
  ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT
  	eng "Too high level of nesting for select"
  ER_UNKNOWN_ERROR  
          eng "Unknown error"
sql/sql_partition.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
sql/sql_plugin.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
sql/sql_prepare.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
  ER_UNKNOWN_STMT_HANDLER  
          eng "Unknown prepared statement handler (%.*s) given to %s"
  length value (for '%.*s') must be 'int', per the doc of printf()
  and the code of my_vsnprintf().
sql/sql_show.cc:
  ER_OUTOFMEMORY HY001 S1001
          eng "Out of memory; restart server and try again (needed %d bytes)"
sql/sql_table.cc:
  ER_TOO_BIG_FIELDLENGTH 42000 S1009
          eng "Column length too big for column '%-.192s' (max = %lu); use BLOB or TEXT instead"
sql/table.cc:
  ER_NOT_FORM_FILE  
          eng "Incorrect information in file: '%-.200s'"
  ER_COL_COUNT_DOESNT_MATCH_PLEASE_UPDATE
          eng "Column count of mysql.%s is wrong. Expected %d, found %d. Created with MySQL %d, now running %d. Please use mysql_upgrade to fix this error."
  table->s->mysql_version is ulong.
sql/unireg.cc:
  ER_TOO_LONG_TABLE_COMMENT
    eng "Comment for table '%-.64s' is too long (max = %lu)"
  ER_TOO_LONG_FIELD_COMMENT
    eng "Comment for field '%-.64s' is too long (max = %lu)"
  ER_TOO_BIG_ROWSIZE 42000 
          eng "Row size too large. The maximum row size for the used table type, not counting BLOBs, is %ld. You have to change some columns to TEXT or BLOBs"
2011-05-16 22:04:01 +02:00
Vinay Fisrekar
91133804d1 Adding bug scenario for data types in main suite
Impementing Test Review Comment.
      
Bug test scenario:      
SELECT is not returning result set for "equal" (=) and "NULL safe equal
operator"  (<=>) on BIT data type. Extending this scenario for all data types
2011-05-14 21:44:49 +05:30
Bjorn Munch
f66763a3ef merge from 5.1 main 2011-05-12 14:08:47 +02:00
Tatjana Azundris Nuernberg
280dce482b auto-merge 2011-05-12 05:43:53 +01:00
Tatjana Azundris Nuernberg
9990ab901b auto-merge Bug#11762799/Bug#55436 2011-05-12 03:41:51 +01:00
Serge Kozlov
79e4b561b7 WL#5867
Replaced the error code by error name
2011-05-09 23:14:24 +04:00
Karen Langford
83f19ef457 Merge from mysql-5.1.57-release 2011-05-06 10:03:02 +02:00
Luis Soares
902e64dafe BUG#12354268
Automerged bzr bundle from bug report:
luis.soares@oracle.com-20110505224815-6ob90n7suxsoizvs.bundle
2011-05-06 00:54:36 +01:00
Luis Soares
8a08fd4341 BUG#11762616: BUG#55229: 'POSTION'
Fix for all "postion" in Oracle files (s/postion/position). 
Updated the copyright notices where needed.
2011-05-06 00:46:53 +01:00
Luis Soares
0efb452e5e BUG#12354268: MYSQLBINLOG --BASE64-OUTPUT=DECODE-ROWS DOES NOT
WORK WITH --START-POSITION
      
If setting --start-position to start after the FD event, mysqlbinlog
will output an error stating that it has not found an FD event.
However, its not that mysqlbinlog does not find it but rather that it
does not processes it in the regular way (i.e., it does not print it).
Given that one is using --base64-output=DECODE-ROWS then not printing
it is actually fine.
      
To fix this, we make mysqlbinlog not to complain when it has not
printed the FD event, is outputing in base64, but is decoding the
rows.
2011-05-05 23:48:15 +01:00
Tatiana Azundris Nurnberg
9d80d48806 auto-merge conservative fix for Bug#55436/Bug#11762799 2011-05-05 06:39:38 +01:00
Alexander Nozdrin
16f26d2aaf Patch for Bug#12394306: the sever may crash if mysql.event is corrupted.
The problem was that wrong structure of mysql.event was not detected and
the server continued to use wrongly-structured data.

The fix is to check the structure of mysql.event after opening before
any use. That makes operations with events more strict -- some operations
that might work before throw errors now. That seems to be Ok.

Another side-effect of the patch is that if mysql.event is corrupted,
unrelated DROP DATABASE statements issue an SQL warning about inability
to open mysql.event table.
2011-05-04 16:59:24 +04:00
Bjorn Munch
659a5469c3 Bug 43247: SUITE/<SUITE NAME>/INCLUDE: NO SUCH FILE OR DIRECTORY
The originally reported dirs have been removed
But found suite/bugs, removed from mysql-test/Makefile.am
2011-05-03 16:08:25 +02:00
Vasil Dimov
1607f4aa21 Merge mysql-5.1-innodb -> mysql-5.1 2011-05-02 12:49:19 +03:00
Vasil Dimov
6f7d0f182d Sync 5.1 .inc file with 5.5 due to a missing changeset
Add extra codes to wait_until_disconnected.inc that are present in 5.5,
but not in 5.1. The missing codes cause innodb_bug59641 to fail in 5.1 on
Windows PB2 runs. The addition of those codes in 5.5 was done in
luis.soares@sun.com-20090930233215-aup3kxy4j6ltvjfp
2011-04-29 14:04:28 +03:00
Mattias Jonsson
044bf3b6b3 bug#11765667: bug#58655: ASSERTION FAILED, SERVER CRASHES WITH MYSQLD GOT SIGNAL 6
The partitioning engine checked the auto_increment column even if it was not to be written,
triggering a DBUG_ASSERT.

Fixed by checking if table->write_set for that column was set.
2011-04-29 13:00:16 +02:00
Bjorn Munch
0e1819a4e9 merge from 5.1 main 2011-04-29 10:55:08 +02:00
Mattias Jonsson
401941c258 Post push fix for bug#11766249 bug#59316
Partitions can have different ref_length (position data length).
Removed DBUG_ASSERT which crashed debug builds when using
MAX_ROWS on some partitions.
2011-04-27 17:51:06 +02:00
Sergey Glukhov
a60c39a2ff Bug#11889186 60503: CRASH IN MAKE_DATE_TIME WITH DATE_FORMAT / STR_TO_DATE COMBINATION
calc_daynr() function returns negative result
if malformed date with zero year and month is used.
Attempt to calculate week day on negative value
leads to crash. The fix is return NULL for
'W', 'a', 'w' specifiers if zero year and month is used.
Additional fix for calc_daynr():
--added assertion that result can not be negative
--return 0 if zero year and month is used


mysql-test/r/func_time.result:
  test case
mysql-test/t/func_time.test:
  test case
sql-common/my_time.c:
  --added assertion that result can not be negative
  --return 0 if zero year and month is used
sql/item_timefunc.cc:
  eturn NULL for 'W', 'a', 'w' specifiers
  if zero year and month is used.
2011-04-27 11:35:57 +04:00
Vasil Dimov
6308205f05 Merge mysql-5.1 -> mysql-5.1-innodb 2011-04-21 11:08:05 +03:00
Bjorn Munch
91eebaaef4 Bug 60907: MYSQL-TEST/LIB/MY/SAFEPROCESS/SAFE_PROCESS.PL USES HARDCODED SIGNAL NUMBE
Replaced the hardcoded 9 with 'KILL'
2011-04-20 14:58:53 +02:00
Sergey Glukhov
90bbf9d615 Bug#11765923 58937: MANY VALGRIND ERRORS AFTER GROUPING BY RESULT OF DECIMAL COLUMN FUNCTION
Bug#11764671  57533: UNINITIALISED VALUES IN COPY_AND_CONVERT (SQL_STRING.CC) WITH CERTAIN CHA
When ROUND evaluates decimal result it uses Item::decimal
value as fraction value for the result. In some cases
Item::decimal is greater than real result fraction value
and uninitialised memory of result(decimal) buffer can be
used in further calculations. Issue is introduced by
Bug33143 fix. The fix is to remove erroneous assignment.


mysql-test/r/func_math.result:
  test case
mysql-test/t/func_math.test:
  test case
sql/item_func.cc:
  remove erroneous assignment
2011-04-20 11:39:20 +04:00
Serge Kozlov
dba184237a BUG#12371924
Update test case
2011-04-18 23:59:15 +04:00
Bjorn Munch
060df92b2f Bug MTR FAILS TO FIND WARNINGS IN SERVER LOG WITH --VALGRIND COMBINED WITH --DEBUG
With this combination, outoput was directed to .trace but not all
      parts of MTR was aware of this.
Replace .err with .trace at the earliest possible place
2011-04-18 15:35:14 +02:00
Sven Sandberg
7b1967ad4e test fails on more platforms, removed @freebsd from default.experimental. 2011-04-18 14:42:14 +02:00
Martin Hansson
8dabe8aa92 Bug 11758558 - 50774: WRONG RESULTSET WHEN TIMESTAMP VALUES ARE APPENDED WITH
.0

The bug was fixed by the patch for bug number BUG 11763109 - 55779: SELECT
DOES NOT WORK PROPERLY IN MYSQL SERVER VERSION "5.1.42 SUSE MYSQL (Exact same
fix as was proposed for this bug.) Since the motivation for the two bug
reports was completely different, however, it still makes sense to push the
test case.

This patch contains only the test case.
2011-04-18 10:44:41 +02:00
Bjorn Munch
0c36269494 merge from 5.1 main 2011-04-15 15:51:31 +02:00
Sergey Glukhov
bba7b9ca0c Bug#11765139 58069: LOAD DATA INFILE: VALGRIND REPORTS INVALID MEMORY READS AND WRITES WITH U
Some multibyte sequences could be considered by my_mbcharlen() functions
as multibyte character but more exact my_ismbchar() does not think so.
In such a case this multibyte sequences is pushed into 'stack' buffer which
is too small to accommodate the sequence.
The fix is to allocate stack buffer in
compliance with max character length.


mysql-test/r/loaddata.result:
  test case
mysql-test/t/loaddata.test:
  test case
sql/sql_load.cc:
  allocate stack buffer in compliance with max character length.
2011-04-15 12:51:34 +04:00