There was auto-reconnecting by slave earlier than a prescribed by slave_net_timeout value.
The issue happened on 64bit solaris that spotted rather incorrect casting of
the ulong slave_net_timeout into the uint of mysql.options.read_timeout.
Notice, that there is no reason for slave_net_timeout to be of type of ulong.
Since it's primarily passed as arg to mysql_options the type can be made
as uint to avoid all conversion hassles.
That's what the fixes are made.
A "side" effect of the patch is a new value for the max of slave_net_timeout
to be the max of the unsigned int type (therefore to vary across platforms).
Note, a regression test can't be made to run reliably without making it to last over some
20 secs. That's why it is placed in suite/large_tests.
mysql-test/suite/large_tests/r/rpl_slave_net_timeout.result:
the new test results.
mysql-test/suite/large_tests/t/rpl_slave_net_timeout-slave.opt:
Initialization of the option that yields slave_net_timeout's default.
sql/mysql_priv.h:
changing type for slave_net_timeout from ulong to uint
sql/mysqld.cc:
changing type for slave_net_timeout from ulong to uint
sql/sys_vars.cc:
Refining the max value for slave_net_timeout to be as the max for uint type.
on Windows".
On platforms where read-write lock implementation does not
prefer readers by default (Windows, Solaris) server might
have deadlocked while detecting MDL deadlock.
MDL deadlock detector relies on the fact that read-write
locks which are used in its implementation prefer readers
(see new comment for MDL_lock::m_rwlock for details).
So far MDL code assumed that default implementation of
read/write locks for the system has this property.
Indeed, this turned out ot be wrong, for example, for
Windows or Solaris. Thus MDL deadlock detector might have
deadlocked on these systems.
This fix simply adds portable implementation of read/write
lock which prefer readers and changes MDL code to use this
new type of synchronization primitive.
No test case is added as existing rqg_mdl_stability test can
serve as one.
config.h.cmake:
Check for presence of pthread_rwlockattr_setkind_np to be
able to determine if system natively supports read-write
locks for which we can specify if readers or writers should
be preferred.
configure.cmake:
Check for presence of pthread_rwlockattr_setkind_np to be
able to determine if system natively supports read-write
locks for which we can specify if readers or writers should
be preferred.
configure.in:
Check for presence of pthread_rwlockattr_setkind_np to be
able to determine if system natively supports read-write
locks for which we can specify if readers or writers should
be preferred.
include/my_pthread.h:
Added support for portable read-write locks which prefer
readers.
To do so extended existing my_rw_lock_t implementation to
support selection of whom to prefer depending on a flag.
mysys/thr_rwlock.c:
Extended existing my_rw_lock_t implementation to support
selection of whom to prefer depending on a flag.
Added rw_pr_init() function implementing initialization of
read-write locks preferring readers.
sql/mdl.cc:
Use portable read-write locks which prefer readers instead of
relying on that system implementation of read-write locks has
this property (this was true for Linux/NPTL but was false,
for example, for Windows and Solaris).
Added comment explaining why preferring readers is important
for MDL deadlock detector (thanks to Serg for example!).
sql/mdl.h:
Use portable read-write locks which prefer readers instead of
relying on that system implementation of read-write locks has
this property (this was true for Linux/NPTL but was false,
for example, for Windows and Solaris).
Extend and implement the grammar that allows to FLUSH WITH READ LOCK
a list of tables, rather than all of them.
Incompatible grammar change:
Previously one could perform FLUSH TABLES, HOSTS, PRIVILEGES in a single
statement.
After this change, FLUSH TABLES must always be alone on the list.
Judging by the test suite, however, the old extended syntax
was never or very rarely used.
The new statement requires RELOAD ACL global privilege and
LOCK_TABLES_ACL | SELECT_ACL on individual tables.
In other words, it's an atomic combination of LOCK TALBES <list> READ
and FLUSH TABLES <list>, and requires respective privileges.
For additional information about the semantics, please
see WL#5000 and the comment for flush_tables_with_read_lock()
function in sql_parse.cc
mysql-test/r/flush.result:
Update test results (WL#5000).
mysql-test/t/flush.test:
Add test coverage for WL#5000.
sql/sql_yacc.yy:
Allow FLUSH TABLES <table_list> WITH READ LOCK.
Disallow FLUSH TABLES <table_list>, flush_options.
The problem was that ALTER TABLE on a merge table which was locked
using LOCK TABLE ... WRITE, by mistake gave
ER_TABLE_NOT_LOCKED_FOR_WRITE.
During opening of the table to be ALTERed, open_table() tried to
get an upgradable metadata lock. In LOCK TABLEs mode, this lock
must already exist (i.e. taken by LOCK TABLE) as new locks of this
type cannot be acquired for fear of deadlock. So in LOCK TABLEs
mode, open_table() tried to find an existing upgradable lock for
the table to be altered.
The problem was that open_table() also tried to find upgradable
metadata locks for children of merge tables even if no such
locks are needed to execute ALTER TABLE on merge tables.
This patch fixes the problem by making sure that open tables code
only searches for upgradable metadata locks for the merge table
and not for the merge children tables.
The patch also fixes a related bug where an upgradable metadata
lock was aquired outside of LOCK TABLEs mode even if the table in
question was temporary. This bug meant that LOCK TABLES or DDL on
temporary tables by mistake could be blocked/aborted by locks held
on base tables with the same table name by other connections.
Test cases added to merge.test and lock_multi.test.
Attempts to execute RESET statements within a transaction that
had acquired metadata locks, led to an assertion failure on
debug servers. This bug didn't cause any problems on release
builds.
The triggered assert is designed to check that caches are not
flushed or reset while having active transactions. It is triggered
if acquired metadata locks exist that are not from LOCK TABLE or
HANDLER statements.
In this case it was triggered by RESET QUERY CACHE while having
an active transaction that had acquired locks. The reason the
assertion was triggered, was that RESET statements, unlike the
similar FLUSH statements, was not causing an implicit commit.
This patch fixes the problem by making sure RESET statements
commit the current transaction before executing. The commit
causes acquired metadata locks to be released, preventing the
assertion from being triggered.
Incompatible change: This patch changes RESET statements so
that they cause an implicit commit.
Test case added to query_cache.test.
bool MDL_context::try_acquire_lock(MDL_request*)
This assert was triggered in the following way:
1) HANDLER OPEN t1 from connection 1
2) DROP TABLE t1 from connection 2. This will block due to the metadata lock
held by the open handler in connection 1.
3) DML statement (e.g. INSERT) from connection 1. This will close the table
opened by the HANDLER in 1) and release its metadata lock. This is done due
to the pending exclusive metadata lock from 2).
4) DROP TABLE t1 from connection 2 now completes and removes table t1.
5) HANDLER READ from connection 1. Since the handler table was closed in 3),
the handler code will try to reopen the table. First a new metadata lock on
t1 will be granted before the command fails since the table was removed in 4).
6) HANDLER READ from connection 1. This caused the assert.
The reason for the assert was that the MDL_request's pointer to the lock
ticket was not reset when the statement failed. HANDLER READ then tried to
acquire a lock using the same MDL_request object, triggering the assert.
This bug was only noticeable on debug builds and did not cause any problems
on release builds.
This patch fixes the problem by assuring that the pointer to the metadata
lock ticket is reset when reopening of handler tables fails.
Test case added to handler.inc
- Remove INSTALL-BINARY from installed docs directory, we provide a copy
in the root directory (but perhaps this should be revisited later).
- Disable audit_null and daemon_example plugins.
- Fix the docs directory.
- Remove mysql-test/Makefile.in
- Build and install mysql_tzinfo_to_sql
- Remove share/charsets/languages.html
This patch prevents system threads and system table accesses from
using user-specified values for "lock_wait_timeout". Instead all
such accesses are done using the default value (1 year).
This prevents background tasks (such as replication, events,
accessing stored function definitions, logging, reading time-zone
information, etc.) from failing in cases where the global value
of "lock_wait_timeout" is set very low.
The patch also simplifies the open tables API. Rather than adding
another convenience function for opening and locking system tables,
this patch removes most of the existing convenience functions for
open_and_lock_tables_derived(). Before, open_and_lock_tables() was
a convenience function that enforced derived tables handling, while
open_and_lock_tables_derived() was the main function where derived
tables handling was optional. Now, this convencience function is
gone and the main function is renamed to open_and_lock_tables().
No test case added as it would have required the use of --sleep to
check that system threads and system tables have a different timeout
value from the user-specified "lock_wait_timeout" system variable.
It appears that stack overflow checks for recusrive stored procedure
calls, that run in the normal server, did not work in embedded and were
dummified with preprocessor magic( #ifndef EMBEDDED_SERVER ).
The fix is to remove ifdefs, there is no reason not to run overflow checks
and crash in deeply recursive calls.
Note: Start of the stack (thd->thread_stack variable) in embedded is not
necessarily exact but stil provides the best guess. Unless the caller of
mysql_read_connect() is already deep in the stack, thd->thread_stack
variable should approximate stack start address well.
There was an erroneous parameter when calling flush_master_info
from write_ignored_events_info_to_relay_log which could lead to a
server crash. This happens because the I/O thread releases the
log_lock before calling the flush_master_info.
Set the function to call flush_master_info with third parameter
to true, so that the mutex is properly taken.
The task is to
(a) add a comment on indexes and
(b) increase the maximum length of column, table and the new index comments.
The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
an INFORMATION_SCHEMA table
When a prepared statement using a merged view containing an information
schema table was executed, a metadata lock of the view was not taken.
This meant that it was possible for concurrent view DDL to execute,
thereby breaking the binary log. For example, it was possible
for DROP VIEW to appear in the binary log before a query using the view.
This also happened when a statement in a stored routine was executed a
second time.
For such views, the information schema table is merged into the view
during the prepare phase (or first execution of a statement in a routine).
The problem was that we took a short cut and were not executing full-blown
view opening during subsequent executions of the statement. As a result,
a metadata lock on the view was not taken to protect the view definition.
This patch resolves the problem by making sure a metadata lock is taken
for views even after information schema tables are merged into them.
Test cased added to view.test.
Multi_polygon::centroid() has an error in the implementation
per-file messages:
sql/spatial.cc
Bug#38959 archive_gis fails due to rounding difference
multi_polygon::centroid() implementation fixed
WL#5154 was a task for formally deprecating and removing items that
were mentioned in the manual as having been deprecated since MySQL
4.1 or 5.0, but that had never been removed.
Since WL#5154 was created, examination of mysqld.cc, mysql.cc, and
mysqldump.c reveals additional deprecations not mentioned in the
manual. (In some cases, the items are simply not mentioned in the
5.1+ manuals.)
This is a follow-on task to deprecate and remove these additional
items.
The deprecation happened in MySQL 5.1, and the options/variables
are now removed from the code.
client/mysql.cc:
--no-tee is now removed
client/mysqldump.c:
--all is now removed
-a now points to --create-options
sql/mysqld.cc:
delay-key-write-for-all-tables is removed
--enable-locking is removed
--log-update is removed
--skip-locking is removed
--skip-symlink is removed
--sql-bin-update-same is removed
--warnings is removed
--record-buffer is removed
A set of program options and variables was deprecated in
MySQL 5.1, and is hereby removed.
client/mysql.cc:
--no-auto-rehash (-A) is no longer deprecated
--no-named-commands (-g) is now removed
--skip-line-numbers (-L) is no longer deprecated
--set-variable (-O) is now removed
--no-pager is now removed
client/mysqlbinlog.cc:
--position is now removed (use --start-position)
-j is now equivalent with --start-position
client/mysqldump.c:
--first-slave is now removed
--no-set-names (-N) is now removed
--set-variable (-O) is now removed
mysql-test/include/default_mysqld.cnf:
default-character-set is removed as an option
character-set-server is equivalent.
mysql-test/t/bug47671-master.opt:
default-character-set option is removed
character-set-server is equivalent
mysql-test/t/ctype_latin1_de-master.opt:
default-character-set option is removed
character-set-server is equivalent
mysql-test/t/ctype_ucs2_def-master.opt:
default-collation is removed
collation-server is equicalent
scripts/mysqld_multi.sh:
--config-file has been superseded by
--defaults-extra-file
sql/mysql_priv.h:
Removed the version number in the deprecation
warning text, as decided by ServerPT.
sql/mysqld.cc:
--default-character-set (-C) is removed
--default-collation is removed
--log-long-format (-0) is removed
--safe-show-database is removed
--set-variable (-O) is removed
sql/sql_yacc.yy:
The FRAC_SECOND keyword is removed
sql/sys_vars.cc:
The sql_log_update system variable is removed
MDL_lock::find_deadlock".
On some platforms deadlock detector in metadata locking
subsystem under certain conditions might have exhausted
stack space causing server crashes.
Particularly this caused failures of rqg_mdl_stability
test on Solaris in PushBuild.
During search for deadlock MDL deadlock detector could
sometimes encounter loop in the waiters graph in which
MDL_context which has started search for a deadlock
does not participate. In such case our algorithm will
continue looping assuming that either this deadlock will
be resolved by MDL_context which has created it (i.e.
by one of loop participants) or maximum search depth
will be reached.
Since max search depth was set to 1000 in the latter case
on platforms where each iteration of deadlock search
algorithm needs more than DEFAULT_STACK_SIZE/1000 bytes
of stack (around 192 bytes for 32-bit and around 256 bytes
for 64-bit platforms) we might have exhausted stack space.
This patch solves this problem by reducing maximum search
depth for MDL deadlock detector to 32. This should be safe
at the moment as it is unlikely that each iteration of the
current deadlock detector algorithm will consume more than
1K of stack (thus total amount of stack required can't be
more than 32K) and we require at least 80K of stack in order
to open any table. Also this value should be (hopefully) big
enough to not cause too much false deadlock errors (there
is an anecdotal evidence that real-life deadlocks are
typically shorter than that).
Additional reasearch should be conducted in future in order
to determine the more optimal value of maximum search depth.
This patch does not include test case as existing
rqg_mdl_stability test can serve as one.
This patch removes the unused server variable
"table_lock_wait_timeout".
mysql-test/r/variables.result:
Updated the test for Bug#28580 to reflect that
"table_lock_wait_timeout" no longer exists.
mysql-test/t/variables.test:
Updated the test for Bug#28580 to reflect that
"table_lock_wait_timeout" no longer exists.
TEMPORARY + HANDLER + LOCK + SP".
Server crashed when one:
1) Opened HANDLER or acquired global read lock
2) Then locked one or several temporary tables with
LOCK TABLES statement (but no base tables).
3) Then issued any statement causing commit (explicit
or implicit).
4) Issued statement which should have closed HANDLER
or released global read lock.
The problem was that when entering LOCK TABLES mode in the
scenario described above we incorrectly set transactional
MDL sentinel to zero. As result during commit all metadata
locks were released (including lock for open HANDLER or
global metadata shared lock). Indeed, attempt to release
metadata lock for the second time which happened during
HANLDER CLOSE or during release of GLR caused crash.
This patch fixes problem by changing MDL_context's
set_trans_sentinel() method to set sentinel to correct
value (it should point to the most recent ticket).
mysql-test/include/handler.inc:
Added test for bug #51136 "Crash in pthread_rwlock_rdlock on
TEMPORARY + HANDLER + LOCK + SP".
mysql-test/r/flush.result:
Updated test results (see flush.test).
mysql-test/r/handler_innodb.result:
Updated test results (see include/handler.inc).
mysql-test/r/handler_myisam.result:
Updated test results (see include/handler.inc).
mysql-test/t/flush.test:
Added additional coverage for bug #51136 "Crash in
pthread_rwlock_rdlock on TEMPORARY + HANDLER + LOCK +
SP".
sql/mdl.h:
When setting new value of transactional sentinel use
pointer to the most recent ticket instead of value
returned by MDL_context::mdl_savepoint().
This allows to handle correctly situation when the new
value of sentinel should be the same as its current value
(MDL_context::mdl_savepoint() returns NULL in this case).
DDL workload".
When a RENAME TABLE or LOCK TABLE ... WRITE statement which
mentioned the same table several times were aborted during
the process of acquring metadata locks (due to deadlock
which was discovered or because of KILL statement) server
might have crashed.
When attempt to acquire all locks requested had failed we
went through the list of requests and released locks which
we have managed to acquire by that moment one by one. Since
in the scenario described above list of requests contained
duplicates this led to releasing the same ticket twice and
a crash as result.
This patch solves the problem by employing different approach
to releasing locks in case of failure to acquire all locks
requested.
Now we take a MDL savepoint before starting acquiring locks
and simply rollback to it if things go bad.
mysql-test/r/lock_multi.result:
Updated test results (see lock_multi.test).
mysql-test/t/lock_multi.test:
Added test case for bug #51134 "Crash in MDL_lock::destroy
on a concurrent DDL workload".
sql/mdl.cc:
MDL_context::acquire_locks():
When attempt to acquire all locks requested has failed do
not go through the list of requests and release locks which
we have managed to acquire one by one.
Since list of requests can contain duplicates such approach
may lead to releasing the same ticket twice and a crash as
result.
Instead use the following approach - take a MDL savepoint
before starting acquiring locks and simply rollback to it
if things go bad.
In POSIX systems, the file descriptor set used in the select(2)
system call is represented by a bit vector of size FD_SETSIZE.
When select(2) is used on file/socket descriptors with a value
that is beyond this size, unpredictable errors may occur.
In this case, the error happens when there are a large number
of tables that need repair. These tables are opened before
the sockets for incoming connections are acquired, resulting
in these sockets getting descriptor id which is higher than
FD_SETSIZE.
Replacing the call to select(2) with poll(2) fixes the problem,
as poll takes an array of the wanted descriptors, instead of
a bit vector.
MS Windows has a different implementation of 'select', and is not
affected by this bug.
configure.in:
Added a test for the <poll.h> file
sql/mysqld.cc:
Restructured some of the code to reduce the number of
#ifdef's. Removed some HP/UX 10-specific code.
function with distinct.
Loose index scan is used to find MIN/MAX values using appropriate index and
thus allow to avoid grouping. For each found row it updates non-aggregated
fields with values from row with found MIN/MAX value.
Without loose index scan non-aggregated fields are copied by end_send_group
function. With loose index scan there is no need in end_send_group and
end_send is used instead. Non-aggregated fields still need to be copied and
this was wrongly implemented in QUICK_GROUP_MIN_MAX_SELECT::get_next.
WL#3220 added a case when loose index scan can be used with end_send_group to
optimize calculation of aggregate functions with distinct. In this case
the row found by QUICK_GROUP_MIN_MAX_SELECT::get_next might belong to a next
group and copying it will produce wrong result.
Update of non-aggregated fields is moved to the end_send function from
QUICK_GROUP_MIN_MAX_SELECT::get_next.
mysql-test/r/group_min_max.result:
Added a test case for the bug#50539.
mysql-test/t/group_min_max.test:
Added a test case for the bug#50539.
sql/opt_range.cc:
Bug#50539: Wrong result when loose index scan is used for an aggregate
function with distinct.
Update of non-aggregated fields is moved to the end_send function from
QUICK_GROUP_MIN_MAX_SELECT::get_next.
sql/sql_select.cc:
Bug#50539: Wrong result when loose index scan is used for an aggregate
function with distinct.
Update of non-aggregated fields is moved to the end_send function from
QUICK_GROUP_MIN_MAX_SELECT::get_next.
failed in enter_locked_tables_mode".
Server was aborted due to assertion failure when one tried to
execute statement requiring prelocking (i.e. firing triggers
or using stored functions) while having open HANDLERs.
The problem was that THD::enter_locked_tables_mode() method
which was called at the beginning of execution of prelocked
statement assumed there are no open HANDLERs. It had to do
so because corresponding THD::leave_locked_tables_mode()
method was unable to properly restore MDL sentinel when
leaving LOCK TABLES/prelocked mode in the presence of open
HANDLERs.
This patch solves this problem by changing the latter method
to properly restore MDL sentinel and thus removing need for
this assumption. As a side-effect, it lifts unjustified
limitation by allowing to keep HANDLERs open when entering
LOCK TABLES mode.
mysql-test/include/handler.inc:
Adjusted tests after making LOCK TABLES not to close
open HANDLERs. Added coverage for bug #50908
"Assertion `handler_tables_hash.records == 0' failed
in enter_locked_tables_mode".
mysql-test/r/handler_innodb.result:
Updated test results (see include/handler.inc).
mysql-test/r/handler_myisam.result:
Updated test results (see include/handler.inc).
sql/mysql_priv.h:
Introduced mysql_ha_move_tickets_after_trans_sentinel()
routine which allows to move tickets for metadata locks
corresponding to open HANDLERs after transaction sentinel.
sql/sql_class.cc:
Changed THD::leave_locked_tables_mode() to correctly restore
MDL sentinel value in the presence of open HANDLERs.
sql/sql_class.h:
Removed assert from THD::enter_locked_tables_mode() as we
no longer have to close HANDLERs when entering LOCK TABLES
or prelocked modes. Instead we keep them open and correctly
restore MDL sentinel value after leaving them.
Removal of assert also fixes problem from the bug report.
sql/sql_handler.cc:
Introduced mysql_ha_move_tickets_after_trans_sentinel()
routine which allows to move tickets for metadata locks
corresponding to open HANDLERs after transaction sentinel.
sql/sql_parse.cc:
We no longer have to close HANDLERs when entering LOCK TABLES
mode. Instead we keep them open and simply correctly restore
MDL sentinel value after leaving this mode.
--slave-load-tm
The MDL_SHARED lock was introduced for an object in 5.4, but the 'TABLE_LIST'
object was not initialized with the MDL_SHARED lock when applying event with
LOAD DATA INFILE into table. So the failure is caused when checking the
MDL_SHARED lock for the object.
To fix the problem, the 'TABLE_LIST' object was initialized with the MDL_SHARED
lock when applying event with LOAD DATA INFILE into table.
--slave-load-tm
The MDL_SHARED lock was introduced for an object in 5.4, but the 'TABLE_LIST'
object was not initialized with the MDL_SHARED lock when applying event with
LOAD DATA INFILE into table. So the failure is caused when checking the
MDL_SHARED lock for the object.
To fix the problem, the 'TABLE_LIST' object was initialized with the MDL_SHARED
lock when applying event with LOAD DATA INFILE into table.
mysql-test/suite/rpl/t/disabled.def:
Got rid of the line for enabling 'rpl_cross_version' test.
causing crashes!
Adding a SPATIAL INDEX on a non-geometrical column caused a
segmentation fault when the table was subsequently
inserted into.
A test was added in mysql_prepare_create_table to explicitly
check whether non-geometrical columns are used in a
spatial index, and throw an error if so.
mysql-test/t/gis.test:
Added test cases to verify that only geometrical
columns can get a spatial index.
In addition, verify that only a single geom.
column can participate in a spatial index.
corruption and crash results
An index creation statement where the index key
is larger/wider than the column it references
should throw an error.
A statement like:
CREATE TABLE t1 (a CHAR(1), PRIMARY KEY (A(255)))
did not error, but a segmentation fault followed when
an insertion was attempted on the table
The partial key validiation clause has been
restructured to (hopefully) better document which
uses of partial keys are valid.
