expression cols.
The problem was that MYSQL_FIELD::org_name was set for MIN() and MAX()
functions (COUNT() is also mentioned in the bug report but was already
fixed).
After this patch for expressions MYSQL_FIELD::name is set to either
expression itself or its alias, and other data origin fields of
MYSQL_FILED (db, org_table, table, org_name) are empty strings.
sql/item_sum.cc:
For expressions only col_name should be non-empty string.
tests/mysql_client_test.c:
Add test case for bug#21635: MYSQL_FIELD struct's member strings seem
to misbehave for expression cols.
Make Prepared_stmt_count a global status variable, accessible via
SHOW STATUS LIKE 'Prepared_stmt_count';. Documentation should be
updated.
mysql-test/r/ps.result:
Update result for bug#16365: Prepared Statements: DoS with too many
open statements, according to bug#23159: prepared_stmt_count should be
status variable.
mysql-test/t/ps.test:
Update test case for bug#16365: Prepared Statements: DoS with too many
open statements, according to bug#23159: prepared_stmt_count should be
status variable.
sql/mysqld.cc:
Add Prepared_stmt_count as global status variable.
sql/set_var.cc:
Remove prepared_stmt_count as system variable.
into mysql.com:/home/hf/work/mysql-4.1-mrg
include/mysql.h:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/t/rename.test:
Auto merged
mysql-test/t/subselect.test:
Auto merged
sql-common/client.c:
Auto merged
sql/sql_class.h:
Auto merged
Makefile.am:
merging
client/mysqltest.c:
merging
mysql-test/t/mysql_client.test:
merging
The problem was that some functions (namely IN() starting with 4.1, and
CHAR() starting with 5.0) were returning NULL in certain conditions,
while they didn't set their maybe_null flag. Because of that there could
be some problems with 'IS NULL' check, and statements that depend on the
function value domain, like CREATE TABLE t1 SELECT 1 IN (2, NULL);.
The fix is to set maybe_null correctly.
mysql-test/r/func_in.result:
Add result for bug#17047: CHAR() and IN() can return NULL without
signaling NULL result.
mysql-test/t/func_in.test:
Add test case for bug#17047: CHAR() and IN() can return NULL without
signaling NULL result.
sql/item_cmpfunc.cc:
Remove assignment to maybe_null, as it was already set in fix_fields()
based on all arguments, not only on the first.
The server sends a number of columns to the client.
It uses a limited "fast" function for that instead of the
general one. This fast function cannot send numbers larger
than 2 bytes.
This causes the client to expect smaller number of columns.
The client writes outside of the allocated memory buffer
as a result.
Fixed the server to use the general function to send column
count.
Fixed the client to check the column count before writing
column data.
mysql-test/t/mysql_client.test:
Bug #19216: Client crashes on long SELECT
- test case
sql/protocol.cc:
Bug #19216: Client crashes on long SELECT
- renamed the function for bether comprehention
and made it local
- used the right (non-local) function to transfer
the column count in Protocol::send_fields
sql/protocol.h:
Bug #19216: Client crashes on long SELECT
- made optimized net_store_length local
sql-common/client.c:
Bug #19216: Client crashes on long SELECT
- fixed the client to check for older servers (without the fix).
into outpost.site:/home/cps/mysql/trees/4.1-runtime-bug9191
configure.in:
Auto merged
include/my_time.h:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/rename.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql-common/my_time.c:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/time.cc:
Auto merged
mysql-test/t/rename.test:
choose one of the race problem solutions. It was solved
differently in -runtime and mainstream
- When returning metadata for scalar subqueries the actual type of the
column was calculated based on the value type, which limits the actual
type of a scalar subselect to the set of (currently) 3 basic types :
integer, double precision or string. This is the reason that columns
of types other then the basic ones (e.g. date/time) are reported as
being of the corresponding basic type.
Fixed by storing/returning information for the column type in addition
to the result type.
mysql-test/r/subselect.result:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- test case
mysql-test/t/subselect.test:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- test case
sql/item_subselect.cc:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- store and return the field type as well in addition to result type for
single row subqueries
sql/item_subselect.h:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- store and return the field type as well in addition to result type for
single row subqueries
Problem: GROUP_CONCAT on a multi-byte column can truncate
in the middle of a multibyte character when applying
group_concat_max_len limit. It produces an invalid
multi-byte character in the result string.
The second, easier version - reusing old "warning_for_row" flag,
instead of introducing of "result_is_full" - which was
added in the previous commit.
mysql-test/r/func_gconcat.result:
Adding test case
mysql-test/t/func_gconcat.test:
Adding test case
sql/item_sum.cc:
Adding well_formed_len() call not to cut
in the middle of a multi-byte character.
into outpost.site:/home/cps/mysql/trees/4.1-runtime-bug9191
mysql-test/r/func_time.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
The parser is allocating Item_field for references by name in ORDER BY
expressions. Such expressions however may point not only to Item_field
in the select list (or to a table column) but also to an arbitrary Item.
This causes Item_field::fix_fields to throw an error about missing
column.
The fix substitutes Item_field for the reference with an Item_ref when
not pointing to Item_field.
mysql-test/r/order_by.result:
Bug #22457: Column alias in ORDER BY works, but not if in an expression
- test case
mysql-test/t/order_by.test:
Bug #22457: Column alias in ORDER BY works, but not if in an expression
- test case
sql/item.cc:
Bug #22457: Column alias in ORDER BY works, but not if in an expression
- transform the Item_field made by the parser into Item_ref if it
doesn't point to Item_field and it is in allowed context
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
configure.in:
Auto merged
mysql-test/t/ps.test:
Auto merged
sql/handler.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
Auto merged
tests/mysql_client_test.c:
Auto merged
myisam/sort.c:
Manual merge.
mysql-test/r/innodb_mysql.result:
Manual merge.
mysql-test/t/innodb_mysql.test:
Manual merge.
mysys/mf_iocache.c:
Manual merge.
into bodhi.local:/opt/local/work/mysql-4.1-runtime
mysql-test/r/ps.result:
Auto merged
mysql-test/t/func_gconcat.test:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/item_sum.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
tables,alter table
Deadlock could happen if there are delayed insert + flush tables + alter table
running concurrently.
This is fixed by removing a redundant mutex lock when killing a delayed thread.
sql/sql_insert.cc:
Removed redundant delayed thread mutex lock, that could result in a deadlock.
LOCK_delayed_insert is sufficient to be sure that no other thread frees delayed
handler.
(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).
acinclude.m4:
Add new macro to check time_t range
configure.in:
Call the macro to check time_t range
include/my_time.h:
Move time-related defines to proper place.
Add a function to perform a rough check if
a TIMESTAMP value fits into the boundaries.
Note: it is defined as "static inline", as
otherwise libmysql won't compile (due to the
way how gcc handles "inline" directive).
mysql-test/r/func_time.result:
Update test result
mysql-test/r/timezone.result:
Update test result
mysql-test/r/timezone2.result:
Update test result
mysql-test/t/func_time.test:
Add test for Bug#9191 and update test to be consistent
with new TIMESTAMP boundaries
mysql-test/t/timezone.test:
Update old tests to be consistent
with new TIMESTAMP boundaries
mysql-test/t/timezone2.test:
Update tests for convert_tz to be consistent with new
TIMESTAMP boundaries
sql/item_timefunc.cc:
Fix convert_tz to allow dates from the new (extended)
TIMESTAMP range
sql/mysql_priv.h:
Move time handling defaults to my_time.h
sql-common/my_time.c:
Because of increased TIMESTAMP_MAX_VALUE overflows in my_system_gmt_sec()
became possible. Here we make it safe against the overflows by stepping
back from the boundary dates which are likely to trigger them.
sql/time.cc:
Update TIME_to_timestamp to allow conversion of
extended date range
sql/tztime.cc:
Fix new (4.1) implementation of broken-down time representation
to time_t conversion routine to avoid overflows during conversion
of boundary dates
mysql-test/r/timezone4.result:
New BitKeeper file ``mysql-test/r/timezone4.result''
mysql-test/t/timezone4-master.opt:
New BitKeeper file ``mysql-test/t/timezone4-master.opt''
mysql-test/t/timezone4.test:
New BitKeeper file ``mysql-test/t/timezone4.test''
If the user has specified --max-connections=N or --table-open-cache=M
options to the server, a warning could be given that some values were
recalculated, and table-open-cache could be assigned greater value.
Note that both warning and increase of table-open-cache were totally
harmless.
This patch fixes recalculation code to ensure that table-open-cache will
be never increased automatically and that a warning will be given only if
some values had to be decreased due to operating system limits.
No test case is provided because we neither can't predict nor control
operating system limits for maximal number of open files.
sql/mysql_priv.h:
Add constants for table_cache minimum and default values.
sql/mysqld.cc:
Fix max_connections and table_cache_size re-computation.
Backport of the fix for bug #8143: A date with value 0 is treated as a NULL value
mysql-test/r/delete.result:
Fix for bug #23412: delete rows with null date field
- test result
mysql-test/t/delete.test:
Fix for bug #23412: delete rows with null date field
- test case
sql/sql_delete.cc:
Fix for bug #23412: delete rows with null date field
- during SELECT queries processing we convert 'date[time]_field is null'
conditions into 'date[time]_field = 0000-00-00[ 00:00:00]' for not null
DATE and DATETIME fields. To be consistent, we have to do the same for DELETE
queries. So we should call remove_eq_conds() in the mysql_delete() as well.
Also it may simplify and speed up DELETE queries execution.
If the error happens during DELETE IGNORE, nothing could be send to the
client, thus leaving it frozen expecting the reply.
The problem was that if some error occurred, it wouldn't be reported to
the client because of IGNORE, but neither success would be reported.
MySQL 4.1 would not freeze the client, but will report
ERROR 1105 (HY000): Unknown error
instead, which is also a bug.
The solution is to report success if we are in DELETE IGNORE and some
non-fatal error has happened.
mysql-test/r/innodb_mysql.result:
Add result for bug#18819: DELETE IGNORE hangs on foreign key parent
delete.
mysql-test/t/innodb_mysql.test:
Add test case for bug#18819: DELETE IGNORE hangs on foreign key parent
delete.
sql/sql_delete.cc:
Report success if we have got an error, but we are in DELETE IGNORE, and
the error is not fatal (if it is, it would be reported to the client).
into willster.(none):/home/stewart/Documents/MySQL/4.1/bug19914-mk2-merge2
sql/ha_myisammrg.cc:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/sql_select.cc:
Auto merged
the incompatibility was caused by current_stmt member added to the MYSQL
structure.
It's possible to move it to THD structure instead which saves ABI
include/mysql.h:
member moved to the THD structure
libmysqld/lib_sql.cc:
now we use THD member here
sql/sql_class.h:
current_stmt member added for the embedded server
fixes for ndb_* tests broken by previous fix
be more careful in ndb about setting errors on failure of info call (especially
in open)
sql/ha_ndbcluster.cc:
fix some ndb* tests failing due to fix for 19914
be more careful about setting errors on failure of info call
sql/ha_ndbcluster.h:
fix some ndb* tests failing due to fix for 19914
be more careful about setting errors on failure of info call
- compilation on the Alpha platform was broken because the Alpha-specific code was not updated after replacing the SIGRETURN_FRAME_COUNT constant with a variable
If elements a not top-level IN subquery were accessed by an index and
the subquery result set included a NULL value then the quantified
predicate that contained the subquery was evaluated to NULL when
it should return a non-null value.
mysql-test/r/subselect.result:
Added a test case for bug #23478.
mysql-test/t/subselect.test:
Added a test case for bug #23478.
