Fix Bug#50555 "handler commands crash server in my_hash_first()"
as a post-merge fix (the new handler tests are not passing
otherwise).
- in hash.c, don't call calc_hash if ! my_hash_inited().
- add tests and results for the test case for Bug#50555
Bug#16565 mysqld --help --verbose does not order variablesBug#20413 sql_slave_skip_counter is not shown in show variables
Bug#20415 Output of mysqld --help --verbose is incomplete
Bug#25430 variable not found in SELECT @@global.ft_max_word_len;
Bug#32902 plugin variables don't know their names
Bug#34599 MySQLD Option and Variable Reference need to be consistent in formatting!
Bug#34829 No default value for variable and setting default does not raise error
Bug#34834 ? Is accepted as a valid sql mode
Bug#34878 Few variables have default value according to documentation but error occurs
Bug#34883 ft_boolean_syntax cant be assigned from user variable to global var.
Bug#37187 `INFORMATION_SCHEMA`.`GLOBAL_VARIABLES`: inconsistent status
Bug#40988 log_output_basic.test succeeded though syntactically false.
Bug#41010 enum-style command-line options are not honoured (maria.maria-recover fails)
Bug#42103 Setting key_buffer_size to a negative value may lead to very large allocations
Bug#44691 Some plugins configured as MYSQL_PLUGIN_MANDATORY in can be disabled
Bug#44797 plugins w/o command-line options have no disabling option in --help
Bug#46314 string system variables don't support expressions
Bug#46470 sys_vars.max_binlog_cache_size_basic_32 is broken
Bug#46586 When using the plugin interface the type "set" for options caused a crash.
Bug#47212 Crash in DBUG_PRINT in mysqltest.cc when trying to print octal number
Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
Bug#49417 some complaints about mysqld --help --verbose output
Bug#49540 DEFAULT value of binlog_format isn't the default value
Bug#49640 ambiguous option '--skip-skip-myisam' (double skip prefix)
Bug#49644 init_connect and \0
Bug#49645 init_slave and multi-byte characters
Bug#49646 mysql --show-warnings crashes when server dies
2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset.
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking
Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.
The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.
- Incompatible change:
If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.
But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.
Let's consider an example:
A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.
At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.
- Incompatible change:
FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.
------------------------------------------------------------
revno: 2630.13.16
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: WL#4284
timestamp: Sat 2008-07-26 13:38:20 -0300
message:
WL#4284: Transactional DDL locking
SQL statements' effect on transactions.
Currently the MySQL server and its storage engines are not
capable of rolling back operations that define or modify data
structures (also known as DDL statements) or operations that
alter any of the system tables (the mysql database). Allowing
these group of statements to participate in transactions
is unfeasible at this time (since rollback has no effect
whatsoever on them) and goes against the design of our metadata
locking subsystem.
The solution is to issue implicit commits before and after
those statements execution. This effectively confines each of
those statements to its own special transaction and ensures
that metadata locks taken during this special transaction
are not leaked into posterior statements/transactions.
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/r/show_check.result
Text conflict in mysql-test/r/sp-code.result
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/t/disabled.def
Text conflict in mysql-test/t/show_check.test
Text conflict in mysys/my_delete.c
Text conflict in sql/item.h
Text conflict in sql/item_cmpfunc.h
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc
Text conflict in sql/repl_failsafe.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_yacc.yy
Text conflict in storage/myisam/ha_myisam.cc
Corrected results for
stm_auto_increment_bug33029.reject 2009-12-01
20:01:49.000000000 +0300
<andrei> @@ -42,9 +42,6 @@
<andrei> RETURN i;
<andrei> END//
<andrei> CALL p1();
<andrei> -Warnings:
<andrei> -Note 1592 Statement may not be safe to log in statement
format.
<andrei> -Note 1592 Statement may not be safe to log in statement
format.
There should be indeed no Note present because there is in fact autoincrement
top-level query in sp() that triggers inserting in yet another auto-inc table.
(todo: alert DaoGang to improve the test).
------------------------------------------------------------
revno: 2597.42.4
committer: davi@mysql.com/endora.local
timestamp: Tue 2008-04-15 17:29:42 -0300
message:
Bug#36004 mysql_stmt_prepare resets the list of warnings
Although the manual says that "the list of messages is reset
for each new statement that uses a table", the list of messages
is being unconditionally reset for prepare commands.
The solution is to enforce that the prepare command will only
reset the message list if the statement being prepared uses
a table or a warning is pushed.
The reason for the bug is that mysqtest as well as other client tools
running in test suite (mysqlbinlog, mysqldump) will first try to connect
whatever database has created shared memory with default base name
"MySQL" and use this. (Same effect could be seen on Unix if mtr would
not care to calculate "port" and "socket" parameter).
The fix ensures that all client tools and running in mtr use unique
per-database shared memory base parameters, so there is no possibility
to clash with already installed one. We use socket name for shared memory
base (it's known to be unique). This shared-memory-base is written to the
MTR config file to the [client] and [mysqld] sections. Fix made also made
sure all client tools understand and correctly handle --shared-memory-base.
Prior to this patch it was not the case for mysqltest, mysqlbinlog and
mysql_client_test.
All new connections done from mtr scripts via connect() will by default
set shared-memory-base. And finally, there is a possibility to force
shared memory or pipe connection and overwrite shared memory/pipe base name
from within mtr scripts via optional PIPE or SHM modifier. This functionality
was manually backported from 6.0
(original patch http://lists.mysql.com/commits/74749)
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.
This patch implements:
WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).
WL#4435: Support OUT-parameters in prepared statements.
(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).
Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.
After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.
When using the binary protocol, send the parameters in an additional result
set over the wire. When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.
The following refactoring has been made:
- Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
- A new Protocol::send_result_set_row() was introduced to incapsulate
common functionality for sending row data.
- Signature of Protocol::prepare_for_send() was changed: this operation
does not need a list of items, the number of items is fully sufficient.
The following backward incompatible changes have been made:
- CLIENT_MULTI_RESULTS is now enabled by default in the client;
- CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
----------------------------------------------------------
revno: 2630.2.6
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-27430
timestamp: Mon 2008-05-26 16:12:28 +0400
message:
Cover four special cases of WL#4166 with tests:
- when the query cache is disabled at the time of prepared statement
reprepare
- when long data parameters are used
- when character_set_connection != character_set_client, and a parameter
conversion takes place
- when parameter data is out of acceptable range, e.g. year 10000 is
supplied as part of MYSQL_TYPE_DATETIME value. The server is supposed
to warn in such case.
added code to exit a tool if the forced config file wasn't found
per-file comments:
client/mysql.cc
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysql_upgrade.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqladmin.cc
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqlcheck.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqldump.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqlimport.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqlshow.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
client/mysqlslap.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
mysql-test/t/mysql.test
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
test added
sql/mysqld.cc
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
storage/myisam/myisamchk.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
storage/myisam/myisampack.c
Bug#47216 programs should quit if the file specified by --defaults-file option isn't found
added code to exit a tool if the forced config file wasn't found
given an already connected MYSQL handle
mysql_real_connect() did not check whether the MYSQL connection
handler was already connected and connected again even if so.
Now a CR_ALREADY_CONNECTED error is returned.
The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).
The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.
Post-merge fix: test case could fail due to a conversion of the
max_join_size value to a integer. Fixed by preserving the value
as a string for comparison purposes.
without proper formatting
The problem is that a suitably crafted database identifier
supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
and thereby a denial of service. The database name is printed
to the log without using a format string, so potential
attackers can control the behavior of my_b_vprintf() by
supplying their own format string. A CREATE or DROP privilege
would be required.
This patch supplies a format string to the printing of the
database name. A test case is added to mysql_client_test.
per-file comments:
tests/mysql_client_test.c
the test for bug 37956 isn't relevant anymore.
The query there 'select point(?,?)' doesn't produce an error.
This is a back port from 5.1 to 5.0.
Fix for BUG 20023: mysql_change_user() resets the value
of SQL_BIG_SELECTS.
The bug was that SQL_BIG_SELECTS was not properly set
in COM_CHANGE_USER.
The fix is to update SQL_BIG_SELECTS properly.
