Feature from Eric Bergen, CLA signed 2007-06-27.
Adds new mysql client option "--auto-vertical-output", which causes
the client to test whether a result table is too wide for the current
window (where available) and emit vertical results in that case.
Otherwise, it sends normal tabular results.
client/client_priv.h:
Add another enum value to client options, for automatic vertical output.
client/mysql.cc:
Add another command-line option, "auto-vertical-output".
Add functions to get the terminal width and functions to get the widths of fields.
Use them together to emit vertical output when some output table is too wide to
fit in the terminal. If the terminal doesn't support reading its width, then assume
80-positions wide.
mysql-test/r/mysql.result:
Show that various select statements do work as expected. Wide tables become vertical
and narrow ones do not.
mysql-test/t/mysql.test:
Show that various select statements do work as expected.
These should be suitable for a wide range of window capabilities and sizes. Under
extreme circumstances, the results could be arbitrary.
deadlocks
Backport of revno: 2617.68.35
The problem was that if one connection is running a multi-statement
transaction which involves a single partitioned table, and another
connection attempts to alter the table to drop a non-existing partition,
(which of course will fail), the first connection still gets
ER_LOCK_DEADLOCK and cannot proceed anymore.
This bug is no longer reproducable. This has also been tested with the
patch for Bug#46654 "False deadlock on concurrent DML/DDL with partitions,
inconsistent behavior" which concerned a similar problem but where the
ALTER TABLE is semantically correct.
Test case added in partition_sync.test.
Another code-path dropped sign of TIME, presuming all time is positive.
Minds sign now. Patch depends on ChangeSet for 42661.
mysql-test/r/type_time.result:
Show we now no longer ignore sign of TIME-type
in this code-path.
mysql-test/t/type_time.test:
Show we now no longer ignore sign of TIME-type
in this code-path.
sql/item_cmpfunc.cc:
TIME_to_ulonglong() (somewhat obviously) loses sign
of its argument, so we put it back in where needed.
Bug#42662: maketime() and signedness
Item_time_typecast::val_int() dropped sign from
MYSQL_TIME gotten using from get_time().
Propagates sign now.
Backported to 5.5.0 (6.0-codebase revid: 1810.3897.1)
When less than six places are given for microseconds, we zerofill from
the right (leftmost place is always 1/10s). We only did this when all
announced date/time fields were given; now we also format fractional
seconds when more significant fields are left out.
mysql-test/r/func_time.result:
show that we treat fractions of seconds correctly (zerofill from
right to six places) even if we left out fields on the left
mysql-test/t/func_time.test:
show that we treat fractions of seconds correctly (zerofill from
right to six places) even if we left out fields on the left
sql/item_timefunc.cc:
format fractions of seconds even if announced
more significant fields were left out
Backport for 5.5
In non debug builds, the statements:
- SHOW PROCEDURE CODE
- SHOW FUNCTION CODE
used to fail with a "syntax error", which is misleading.
These statements have been changed to return the following error for non
debug builds:
ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
need MySQL built with '--with-debug' to have it working
For debug builds (./configure --with-debug), nothing is changed.
When the query cache is disabled, the server shouldn't attempt to take the
query cache mutex.
By using the command line option --query_cache_type=0, the user can disable
(backport from mysql-pe)
mysql-test/t/query_cache_disabled-master.opt:
* added test case for bug38551
mysql-test/t/query_cache_disabled.test:
* added test case for bug38551
sql/set_var.cc:
* Added before-trigger to verify that query_cache_type wasn't turned off or on during
runtime.
sql/set_var.h:
* Changed order on how the enumeration is processed. By first projecting the
character representation of the variable to a temporary integer we can have
one function instead of two to check if the value is valid.
sql/share/errmsg-utf8.txt:
* Added error message for query cache disabled state
sql/sql_cache.cc:
* If the query cache is disabled at start up, shorten the execution path and avoid
grabbing the query cache mutex each time the invalidate interface methods are called.
sql/sql_cache.h:
* Added new methods to set the query cache into a disabled state.
(backport)
mysql_upgrade script accepts --upgrade-system-tables option,
fixing only system tables in this case.
per-file comments:
client/mysql_upgrade.c
WL#4991 mysql_upgrade --fix-privilege-tables
--upgrade-system-tables option added.
if it is set, the tool won't look for the mysqlcheck then
run_mysqlcheck_fixnames() and run_mysqlcheck_upgrade won't be called.
mysql-test/r/mysql_upgrade.result
WL#4991 mysql_upgrade --fix-privilege-tables
test result added
mysql-test/t/mysql_upgrade.test
WL#4991 mysql_upgrade --fix-privilege-tables
test case added
Disabled execution of this test for embedded server until fix for
bug 41971 'Thread state on embedded server is always "Writing to net"'
is back-ported to this tree.
Concurrent execution of statements which require non-table-level
write locks on several instances of the same table (such as
SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
statement which invokes trigger which tries to update same InnoDB
table directly and through stored function) and statements which
required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
ALTER TABLE, ...) might have resulted in a deadlock.
The problem occured when a thread tried to acquire write lock
(TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
and we failed to detect that this thread already had another instance
of write lock on it (so in fact we were trying to acquire recursive
lock) because there was also another thread holding write lock on the
table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
its lock neither the first thread nor the thread trying to acquire
TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
locked by the first thread) so we ended up with a deadlock.
This patch solves this problem by ensuring that thread which
already has write lock on the table won't wait when it tries
to acquire second write lock on the same table.
mysql-test/r/lock_sync.result:
Added test case for bug #45143 "All connections hang on concurrent
ALTER TABLE".
mysql-test/t/lock_sync.test:
Added test case for bug #45143 "All connections hang on concurrent
ALTER TABLE".
mysys/thr_lock.c:
Ensured that thread can acquire write lock on the table without
waiting if it already has write lock on it even if there are other
threads holding write locks on this table (this is normal situation
for, e.g., TL_WRITE_ALLOW_WRITE type of lock).
Adjusted comments to better explain why it is OK to do so and added
asserts to prevent introduction of scenarios in which this can cause
problems.
Fixed problems:
- "mtr --mem mysql_locale_posix" could fail because of wrong temporary
directory name: var/tmp/ -> $MYSQLTEST_VARDIR/tmp/
- "mtr federated_debug" could fail because of not compiled-in
locale character set. Always run mysqladmin with latin1.
CMakeLists.txt:
Add plugin/semisync subdirectory
mysql-test/mysql-test-run.pl:
Check for semisync dll for Windows
mysql-test/suite/rpl/r/rpl_semi_sync.result:
Update result file
mysql-test/suite/rpl/t/rpl_semi_sync.test:
Test semi-sync on Windows
plugin/semisync/semisync_master.cc:
Define gettimeofday for Windows
Conflicts
=========
Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.
NOTE
====
mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
- "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"
This is the first cset (merge/...) committed after pulling
from mysql-next-mr.
to 5.1 partially. This patch brings what was left to mysql-next-mr.
Original revisions in 6.0:
------------------------------------------------------------
revno: 2617.31.26
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt-bug43138.3
timestamp: Thu 2009-04-30 19:31:30 +0400
message:
Fix for Bug#43138: DROP DATABASE failure does not clean up message list.
The problem was that the high-level function mysql_rm_db() invoked
low-level mysql_rm_table_part2(), which reported low-level error
(Unknown table) if SE refused to delete a table. Also when
mysql_rm_table_part2() reported an error, it didn't add corresponding
warning into the list (because it is used from other places where such
behaviour is required).
The fix is to
1. Remove no_warnings_for_error usage from sql_table.cc
2. Improve internal error handler support in THD, so that
a stack of error handlers is allowed.
3. Create an internal error handler (Drop_table_error_handler)
to silence useless warnings.
4. Use the handler in DROP DATABASE and DROP TABLE statements.
------------------------------------------------------------
revno: 2617.69.38
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-next-bugfixing-bug37431
timestamp: Mon 2009-08-24 21:52:09 +0400
message:
A test case for Bug#37431 (DROP TABLE does not report errors correctly).
------------------------------------------------------------
revno: 2617.31.29
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2009-05-01 17:37:34 +0400
message:
Follow-up for fix for bug "Bug#43138: DROP DATABASE failure
does not clean up message list".
Fixed drop.test failure under non-debug server by moving part
of test dependent on debug-only feature to separate .test file,
which won't be run for non-debug versions of server.
------------------------------------------------------------
revno: 2617.45.17
committer: Sergei Golubchik <serg@mysql.com>
branch nick: 6.0-maria
timestamp: Wed 2009-05-13 20:08:58 +0200
message:
followup for bug#43138
if delete fails with a permission denied error, we want to show it
------------------------------------------------------------
The patch was backported to 5.1 in scope of Bug#42364 by
the following revision:
------------------------------------------------------------
revno: 2497.975.3
committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Fri 2009-07-03 13:22:06 +0500
message:
Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent table
enabled message storing into error message list
for 'drop table' command
------------------------------------------------------------
