Commit graph

31 commits

Author SHA1 Message Date
Gleb Shchepa
ed736379f5 Bug #55424: convert_tz crashes when fed invalid data
The CONVERT_TZ function crashes the server when the
timezone argument is an empty SET field value.

1) The CONVERT_TZ may find a timezone string in the
   tz_names hash.
2) A string representation of the empty SET is a
   String of zero length with the NULL pointer.
3) If the key argument length is zero, hash functions
   do comparison using the length of the record being
   compared against.

I.e. a zero-length String buffer is an invalid
argument for hash search functions, and if String
points to NULL buffer, hashcmp() fails with SEGV
accessing that memory.

The my_tz_find function has been modified to
treat empty Strings as invalid timezone values
to skip unnecessary hash search.
2010-08-06 23:29:37 +04:00
Alfranio Correia
3175a06a13 merge 5.1 --> 5.1-rpl 2008-12-13 19:42:12 +00:00
Georgi Kodinov
6969832813 merged addendum to bug 39920 to 5.1-bugteam 2008-12-01 17:43:51 +02:00
Georgi Kodinov
f0c49a6a7d addendum to the fix for bug #39920 : post-merge test suite fixes 2008-12-01 17:41:06 +02:00
Sven Sandberg
78c8bfdddf BUG#37975: wait_for_slave_* should increase the timeout
Problem 1: tests often fail in pushbuild with a timeout when waiting
for the slave to start/stop/receive error.
Fix 1: Updated the wait_for_slave_* macros in the following way:
- The timeout is increased by a factor ten
- Refactored the macros so that wait_for_slave_param does the work for
the other macros.
Problem 2: Tests are often incorrectly written, lacking a
source include/wait_for_slave_to_[start|stop].inc.
Fix 2: Improved the chance to get it right by adding
include/start_slave.inc and include/stop_slave.inc, and updated tests
to use these.
Problem 3: The the built-in test language command
wait_for_slave_to_stop is a misnomer (does not wait for the slave io
thread) and does not give as much debug info in case of failure as
the otherwise equivalent macro
source include/wait_for_slave_sql_to_stop.inc
Fix 3: Replaced all calls to the built-in command by a call to the
macro.
Problem 4: Some, but not all, of the wait_for_slave_* macros had an
implicit connection slave. This made some tests confusing to read,
and made it more difficult to use the macro in circular replication
scenarios, where the connection named master needs to wait.
Fix 4: Removed the implicit connection slave from all
wait_for_slave_* macros, and updated tests to use an explicit
connection slave where necessary.
Problem 5: The macros wait_slave_status.inc and wait_show_pattern.inc
were unused. Moreover, using them is difficult and error-prone.
Fix 5: remove these macros.
Problem 6: log_bin_trust_function_creators_basic failed when running
tests because it assumed @@global.log_bin_trust_function_creators=1,
and some tests modified this variable without resetting it to its
original value.
Fix 6: All tests that use this variable have been updated so that
they reset the value at end of test.
2008-07-10 18:09:39 +02:00
kroki/tomash@moonlight.home
c19affef54 BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked
The problem was that some facilities (like CONVERT_TZ() function or
server HELP statement) may require implicit access to some tables in
'mysql' database.  This access was done by ordinary means of adding
such tables to the list of tables the query is going to open.
However, if we issued LOCK TABLES before that, we would get "table
was not locked" error trying to open such implicit tables.

The solution is to treat certain tables as MySQL system tables, like
we already do for mysql.proc.  Such tables may be opened for reading
at any moment regardless of any locks in effect.  The cost of this is
that system table may be locked for writing only together with other
system tables, it is disallowed to lock system tables for writing and
have any other lock on any other table.

After this patch the following tables are treated as MySQL system
tables:
  mysql.help_category
  mysql.help_keyword
  mysql.help_relation
  mysql.help_topic
  mysql.proc (it already was)
  mysql.time_zone
  mysql.time_zone_leap_second
  mysql.time_zone_name
  mysql.time_zone_transition
  mysql.time_zone_transition_type

These tables are now opened with open_system_tables_for_read() and
closed with close_system_tables(), or one table may be opened with
open_system_table_for_update() and closed with close_thread_tables()
(the latter is used for mysql.proc table, which is updated as part of
normal MySQL server operation).  These functions may be used when
some tables were opened and locked already.

NOTE: online update of time zone tables is not possible during
replication, because there's no time zone cache flush neither on LOCK
TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
data from cache, while on slave updated data will be loaded from the
time zone tables.
2007-03-09 13:12:31 +03:00
tnurnberg@salvation.intern.azundris.com
655056d32f Bug#16456 RBR: rpl_sp.test expects query to fail, but passes in RBR
Fix tests for new behaviour: an error is thrown if a NON DETERMINISTIC
stored function (SF) is called during statement-based replication (SBR).
2006-11-17 21:30:28 +01:00
petr/cps@owlet.local
3df8165cf9 Merge mysql.com:/home/cps/mysql/trees/5.0-runtime-bug9191
into  mysql.com:/home/cps/mysql/trees/5.1-runtime-bug9191
2006-11-01 18:18:01 +03:00
petr/cps@mysql.com/owlet.local
7974bf90aa Merge mysql.com:/home/cps/mysql/trees/4.1-runtime-bug9191
into  mysql.com:/home/cps/mysql/trees/5.0-runtime-bug9191
2006-11-01 17:35:35 +03:00
petr/cps@mysql.com/owlet.local
3ec542dfbd Fix Bug #9191 "TIMESTAMP/from_unixtime() no longer accepts 2^31-1"
(4.1 version, with post-review fixes)
  
  The fix for another Bug (6439) limited FROM_UNIXTIME() to
  TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT,
  however unix timestamp in general is not considered to be limited 
  by this value. All dates up to power(2,31)-1 are valid.
  
  This patch extends allowed TIMESTAMP range so, that max
  TIMESTAMP value is power(2,31)-1. It also corrects
  FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that
  max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME()
  is fixed accordingly to allow conversion of dates up to
  2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ()
  function to allow extended range of dates.
  
  The main problem solved in the patch is possible overflows
  of variables, used in broken-time representation to time_t
  conversion (required for UNIX_TIMESTAMP).
2006-11-01 16:47:40 +03:00
mats@mysql.com
321d9d842f Bug#19066 (DELETE FROM inconsistency for NDB):
Under row-based replication, DELETE FROM will now always be
replicated as individual row deletions, while TRUNCATE TABLE will
always be replicated as a statement.
2006-06-01 11:53:27 +02:00
dlenev@mysql.com
5cae540501 Merge mysql.com:/home/dlenev/mysql-5.0-bg11081
into  mysql.com:/home/dlenev/mysql-5.1-merges
2006-05-02 23:16:53 +04:00
dlenev@mysql.com
2033f7ba45 Fix for bug#11081 "Using a CONVERT_TZ function in a stored function or
trigger fails".

In cases when CONVERT_TZ() function was used in trigger or stored function
(or in stored procedure which was called from trigger or stored function)
error about non existing '.' table was reported.

Statements that use CONVERT_TZ() function should have time zone related
tables in their table list. tz_init_table_list() function which is used
to produce part of table list containing those tables didn't set
TABLE_LIST::db_length/table_name_length members properly. As result time
zone tables needed for CONVERT_TZ() function were incorrectly handled by
prelocking algorithm and "Table '.' doesn't exist' error was emitted.
This fix changes tz_init_table_list() in such way that it properly inits
TABLE_LIST::table_name_length/db_length members and thus produces table list
which can be handled by prelocking algorithm correctly.
2006-04-24 18:57:00 +04:00
gluh@eagle.intranet.mysql.r18.ru
e9d70e4b97 Fix for bug#8294 Traditional: Misleading error message for invalid CAST to DATE
-issue more correct message for incorrect date|datetime|time values
  -ER_WARN_DATA_OUT_OF_RANGE message is changed
  -added new error message
2005-12-02 15:01:44 +04:00
jimw@mysql.com
dd2f631ec4 Fix number to date conversion so it always honors the NO_ZERO_DATE,
NO_ZERO_IN_DATE, and INVALID_DATES bits of SQL_MODE. (Bug #5906)
2005-07-18 16:12:44 -07:00
jimw@mysql.com
5865330a9e Merge embedded server testing changes from 4.1. 2005-04-01 19:17:15 -08:00
jimw@mysql.com
690183d1a0 Eliminate most of the remaining hardcoded list of tests to skip
by adding check for embedded server within tests and splitting some
tests into multiple test files.
2005-03-29 17:17:46 -08:00
dlenev@mysql.com
2276bfa374 Manual merge of fixes for bugs #7899 "CREATE TABLE .. SELECT .. and
CONVERT_TZ() function does not work well together" and bug #7705 
"CONVERT_TZ() crashes with subquery/WHERE on index column" in 5.0
tree.
2005-01-28 10:22:50 +03:00
dlenev@brandersnatch.localdomain
80282016c2 Fix for bug #7899 "CREATE TABLE .. SELECT .. and CONVERT_TZ() function
does not work well together". Now using simplier and more correct
implementation of st_lex::unlink_first_table()/link_first_table_back() 
(It also nicely handles case when global table list is created because
of implictly used time zone tables). (2nd attempt)

Fix for bug #7705 "CONVERT_TZ() crashes with subquery/WHERE on index
column". Implemented new approach for caching objects for constant
time zone arguments. Now instead of determining whenever these arguments
are constants and performing time zone lookup at fix_fields() stage, we
do it on first get_date() invocation.

Cleanup of global @@time_zone variable handling.
2005-01-26 22:25:02 +03:00
serg@sergbook.mysql.com
a9c7fb9dfd post-merge 2004-12-31 17:59:43 +01:00
serg@sergbook.mysql.com
a04fc26c54 manually merged 2004-12-31 15:26:24 +01:00
serg@sergbook.mysql.com
45ce994e5d post-merge 2004-12-31 11:52:14 +01:00
monty@mysql.com
5e03ebbcad After merge fixes
Cleanup of mi_print_error() handling
Deleted 'merge' directory
2004-12-31 03:47:56 +02:00
monty@mysql.com
d71c030587 After merge fixes 2004-12-31 00:44:00 +02:00
monty@mishka.local
4f4bbfc279 Merge with 4.1 2004-12-22 13:54:39 +02:00
dlenev@brandersnatch.localdomain
4b0882e0a6 Fix for bug #6765 "Implicit access to time zone description
tables requires privileges for them if some table or column level grants
present" (with after-review fixes).

We should set SELECT_ACL for implicitly opened tables in 
my_tz_check_n_skip_implicit_tables() to be able to bypass privilege
checking in check_grant(). Also we should exclude those tables from
privilege checking in multi-update.
2004-12-09 13:31:46 +03:00
monty@mysql.com
afbe601302 merge with 4.1 2004-10-29 19:26:52 +03:00
dlenev@brandersnatch.localdomain
e6a44b719a Fix for bug #6116 "SET time_zone := ... requires access to
mysql.time_zone* tables".

We are excluding implicitly used time zone tables from privilege
checking.
2004-10-21 22:18:00 +04:00
monty@mishka.local
f2941380c4 Strict mode & better warnings
Under strict mode MySQL will generate an error message if there was any conversion when assigning data to a field.
Added checking of date/datetime fields.
If strict mode, give error if we have not given value to field without a default value (for INSERT)
2004-09-28 20:08:00 +03:00
dlenev@brandersnatch.localdomain
f49d4f5350 Fix for bug #4508 "CONVERT_TZ() function with new time zone as param crashes server".
Instead of trying to open time zone tables during calculation of CONVERT_TZ() function
or setting of @@time_zone variable we should open and lock them with the rest of 
statement's table (so we should add them to global table list) and after that use such 
pre-opened tables for loading info about time zones.
2004-08-10 12:42:31 +04:00
dlenev@brandersnatch.localdomain
09ba29e539 WL#1264 "Per-thread time zone support infrastructure".
Added basic per-thread time zone functionality (based on public
domain elsie-code). Now user can select current time zone
(from the list of time zones described in system tables).
All NOW-like functions honor this time zone, values of TIMESTAMP
type are interpreted as values in this time zone, so now
our TIMESTAMP type behaves similar to Oracle's TIMESTAMP WITH
LOCAL TIME ZONE (or proper PostgresSQL type).
  
WL#1266 "CONVERT_TZ() - basic time with time zone conversion 
function".
  
Fixed problems described in Bug #2336 (Different number of warnings 
when inserting bad datetime as string or as number). This required
reworking of datetime realted warning hadling (they now generated 
at Field object level not in conversion functions).
  
Optimization: Now Field class descendants use table->in_use member
instead of current_thd macro.
2004-06-18 10:11:31 +04:00