Commit graph

8778 commits

Author SHA1 Message Date
Venkatesh Duggirala
33f15dc7ac Bug#17283409 4-WAY DEADLOCK: ZOMBIES, PURGING BINLOGS,
SHOW PROCESSLIST, SHOW BINLOGS

Problem:  A deadlock was occurring when 4 threads were
involved in acquiring locks in the following way
Thread 1: Dump thread ( Slave is reconnecting, so on
              Master, a new dump thread is trying kill
              zombie dump threads. It acquired thread's
              LOCK_thd_data and it is about to acquire
              mysys_var->current_mutex ( which LOCK_log)
Thread 2: Application thread is executing show binlogs and
               acquired LOCK_log and it is about to acquire
               LOCK_index.
Thread 3: Application thread is executing Purge binary logs
               and acquired LOCK_index and it is about to
               acquire LOCK_thread_count.
Thread 4: Application thread is executing show processlist
               and acquired LOCK_thread_count and it is
               about to acquire zombie dump thread's
               LOCK_thd_data.
Deadlock Cycle:
     Thread 1 -> Thread 2 -> Thread 3-> Thread 4 ->Thread 1

The same above deadlock was observed even when thread 4 is
executing 'SELECT * FROM information_schema.processlist' command and
acquired LOCK_thread_count and it is about to acquire zombie
dump thread's LOCK_thd_data.

Analysis:
There are four locks involved in the deadlock.  LOCK_log,
LOCK_thread_count, LOCK_index and LOCK_thd_data.
LOCK_log, LOCK_thread_count, LOCK_index are global mutexes
where as LOCK_thd_data is local to a thread.
We can divide these four locks in two groups.
Group 1 consists of LOCK_log and LOCK_index and the order
should be LOCK_log followed by LOCK_index.
Group 2 consists of other two mutexes
LOCK_thread_count, LOCK_thd_data and the order should
be LOCK_thread_count followed by LOCK_thd_data.
Unfortunately, there is no specific predefined lock order defined
to follow in the MySQL system when it comes to locks across these
two groups. In the above problematic example,
there is no problem in the way we are acquiring the locks
if you see each thread individually.
But If you combine all 4 threads, they end up in a deadlock.

Fix: 
Since everything seems to be fine in the way threads are taking locks,
In this patch We are changing the duration of the locks in Thread 4
to break the deadlock. i.e., before the patch, Thread 4
('show processlist' command) mysqld_list_processes()
function acquires LOCK_thread_count for the complete duration
of the function and it also acquires/releases
each thread's LOCK_thd_data.

LOCK_thread_count is used to protect addition and
deletion of threads in global threads list. While show
process list is looping through all the existing threads,
it will be a problem if a thread is exited but there is no problem
if a new thread is added to the system. Hence a new mutex is
introduced "LOCK_thd_remove" which will protect deletion
of a thread from global threads list. All threads which are
getting exited should acquire LOCK_thd_remove
followed by LOCK_thread_count. (It should take LOCK_thread_count
also because other places of the code still thinks that exit thread
is protected with LOCK_thread_count. In this fix, we are changing
only 'show process list' query logic )
(Eg: unlink_thd logic will be protected with
LOCK_thd_remove).

Logic of mysqld_list_processes(or file_schema_processlist)
will now be protected with 'LOCK_thd_remove' instead of
'LOCK_thread_count'.

Now the new locking order after this patch is:
LOCK_thd_remove -> LOCK_thd_data -> LOCK_log ->
LOCK_index -> LOCK_thread_count
2014-05-08 18:13:01 +05:30
Sergei Golubchik
8db4a51815 merge of "BUG#18233051 - FTS: FAILING ASSERTION: NUM_TOKEN < MAX_PROXIMITY_ITEM"
revno: 5826
committer: Shaohua Wang <shaohua.wang@oracle.com>
branch nick: mysql-5.6-bugfix2
timestamp: Wed 2014-02-19 16:41:14 +0800
message:
  BUG#18233051 - FTS: FAILING ASSERTION: NUM_TOKEN < MAX_PROXIMITY_ITEM
2014-05-07 22:36:40 +02:00
Sergei Golubchik
5ffe939a6c perfschema 5.6.17 2014-05-07 16:12:16 +02:00
Sergei Golubchik
374f0751a2 null-merge from perfschema-5.6 merge tree
(only new files and small style changes are accepted)
2014-05-07 10:21:41 +02:00
Sergei Golubchik
04bce7b569 5.6.17 2014-05-07 10:04:30 +02:00
Sergei Golubchik
7226287c06 perfschema 5.6.10 initial commit.
include/mysql/psi/*
2014-05-07 10:02:35 +02:00
Nisha Gopalakrishnan
501de3a027 BUG#18080920: CRASH; MY_REALLOC_STR DEREFERENCES NEGATIVE VALUE
INTO CLIENT_ERRORS ARRAY
              
Analysis:
--------
The client may crash while executing a statement due to
the missing mapping of the server error to it's equivalent
client error.

When trying to reallocate memory for the packet buffer, if
the system is out of memory or the packet buffer is large,
the server errors 'ER_OUT_OF_RESOURCES' or 'ER_PACKET_TOO_LARGE'
is returned respectively. The client error number calculated is
negative and when trying to dereference the array of client 
error messages with the calculated error number, the client
crashes.

Fix:
----
Map the server error returned to it's equivalent client error
prior to dereferencing the array of client error messages.

Note: Test case is not added since it is difficult to simulate
the error condition.
2014-04-24 09:30:21 +05:30
Nisha Gopalakrishnan
56cf9d2db4 BUG#18080920: CRASH; MY_REALLOC_STR DEREFERENCES NEGATIVE VALUE
INTO CLIENT_ERRORS ARRAY
              
Analysis:
--------
The client may crash while executing a statement due to
the missing mapping of the server error to it's equivalent
client error.

When trying to reallocate memory for the packet buffer, if
the system is out of memory or the packet buffer is large,
the server errors 'ER_OUT_OF_RESOURCES' or 'ER_PACKET_TOO_LARGE'
is returned respectively. The client error number calculated is
negative and when trying to dereference the array of client 
error messages with the calculated error number, the client
crashes.

Fix:
----
Map the server error returned to it's equivalent client error
prior to dereferencing the array of client error messages.

Note: Test case is not added since it is difficult to simulate
the error condition.
2014-04-24 09:30:21 +05:30
Sergei Golubchik
06be773cdb Revert revision sergii@pisem.net-20130123151853-xc6i3l11aqv0iykk
Rename back my_init_dynamic_array2() -> init_dynamic_array2()
It happens to be a part of the de facto API :(
2014-03-26 22:26:13 +01:00
Sergei Golubchik
10740939eb 5.5 merge 2014-03-26 22:25:38 +01:00
Michael Widenius
ded448d1d0 MDEV-5905: Creating tmp. memory table kills the server
The reason was that a couple of variables that hold number of rows that was used to calculate buffers was uint and caused an overflow.

Fixed by changing variables that could hold number of rows from uint to ulong and also added a cast for this test.

include/heap.h:
  Reorder to get better alignment. Changed variables that could hold number of rows from uint to ulong
mysql-test/suite/heap/heap.result:
  Added test case
mysql-test/suite/heap/heap.test:
  Added test case
mysql-test/suite/plugins/t/server_audit.test:
  Added sleep as we want to have disconnect logged before we try a new connect
storage/heap/ha_heap.cc:
  Changed variables that could hold number of rows from uint to ulong
  Limit number of rows to 4G  (as most of the variables that holds rows are ulong anyway)
  reset records_changed when key_stat_version is changed to not cause increments for every row changed
storage/heap/ha_heap.h:
  changed records_changed to ulong as this can get big
storage/heap/hp_create.c:
  Changed variables that could hold number of rows from uint to ulong
  Added cast (fixed the original bug)
storage/heap/hp_delete.c:
  Changed variables that could hold number of rows from uint to ulong
storage/heap/hp_open.c:
  Removed not needed cast
storage/heap/hp_write.c:
  Changed variables that could hold number of rows from uint to ulong
support-files/compiler_warnings.supp:
  Removed extra : from supression
2014-03-26 21:58:27 +02:00
Sergei Golubchik
c11c64e972 MDEV-5822 TokuDB fails to compile without partition storage engine 2014-03-24 20:01:55 +01:00
Sergei Golubchik
1fa1ea0f2d MDEV-5404 Can't free data returned by mariadb_dyncol_unpack on windows
add mariadb_dyncol_unpack_free()
2014-03-19 09:58:18 +01:00
unknown
b352969118 MDEV-5914: Parallel replication deadlock due to InnoDB lock conflicts
Due to how gap locks work, two transactions could group commit together on the
master, but get lock conflicts and then deadlock due to different thread
scheduling order on slave.

For now, remove these deadlocks by running the parallel slave in READ
COMMITTED mode. And let InnoDB/XtraDB allow statement-based binlogging for the
parallel slave in READ COMMITTED.

We are also investigating a different solution long-term, which is based on
relaxing the gap locks only between the transactions running in parallel for
one slave, but not against possibly external transactions.
2014-03-21 13:30:55 +01:00
Sergei Golubchik
5d0c01608c 5.2 merge 2014-03-16 21:03:01 +01:00
Sergei Golubchik
e772cbd7b7 5.1 merge 2014-03-16 13:59:44 +01:00
Sergei Golubchik
d7304375e5 mysql-5.1.73 merge 2014-03-15 18:24:15 +01:00
Michael Widenius
e63c03db8d Merge with 10.0-base
Automatic merge, except for server_audit.cc that had to be modified slightly
Changes to xtradb and innobase where ignored was these made no sence for 10.0
2014-03-13 16:43:11 +02:00
Michael Widenius
49ca12a107 Fixed some failing tests
Remove memory warnings if mysql client aborts early
Changed copyright for clients

client/mysql.cc:
  Free memory if get_options fails, so that we don't get warnings from safemalloc
include/welcome_copyright_notice.h:
  Added SkySQL to client copyrights
mysql-test/valgrind.supp:
  Added suppressions for memory leaks from dlopen() for OpenSUSE 12.3
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.result:
  Suppress warning
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.test:
  Suppress warning
2014-03-12 11:24:03 +02:00
Sergey Vojtovich
9836fd5d13 MDEV-5766 - my_atomic_load does memory writes
my_atomic_load() is implemented as __sync_fetch_and_or(var, 0) which
writes or-ed value back to var. Memory writes as such have worse
performance and scalability than reads.

gcc 4.7 and up offers better facility for atomic loads/stores. Use it
whenever it is available.
2014-03-07 11:43:06 +04:00
Michael Widenius
b07f9f72dc Fixed MDEV-5780 "create-big fails in 10.0"
The issue was that create...trigger part of the test suite used a debug_sync point that before was never triggered (in other words, wrong meaningless test).
With the new create ... replace code the debug sync point is triggered and the test case could not handled that.

I fixed this by adding a wait and go for the debug syncpoint in the test.

Removed some compiler warnings from mysql_cond_timedwait


include/mysql/psi/mysql_thread.h:
  Removed compiler warnings
mysql-test/r/create-big.result:
  New test result
mysql-test/t/create-big.test:
  Fixed test case as create_table_select_before_check_if_exists was not before triggered by the code.
2014-03-10 14:08:12 +02:00
Alexander Barkov
89e1715355 MDEV-5372 Make "CAST(time_expr AS DATETIME)" compatible with MySQL-5.6 (and the SQL Standard) 2014-03-07 00:21:25 +04:00
Sergey Vojtovich
b95c8ce530 MDEV-5675 - Performance: my_hash_sort_bin is called too often
Reduced number of my_hash_sort_bin() calls from 4 to 1 per query.
Reduced number of memory accesses done by my_hash_sort_bin().

Details:
- let MDL subsystem use pre-calculated hash value for hash
  inserts and deletes
- let table cache use pre-calculated MDL hash value
- MDL namespace is excluded from hash value calculation, so that
  hash value can be used by table cache as is
- hash value for MDL is calculated as resulting hash value + MDL
  namespace
- extended hash implementation to accept user defined hash function
2014-03-06 16:19:12 +04:00
Sergei Golubchik
cb67dcb618 mysql-5.5.37 selective merge 2014-03-27 22:26:58 +01:00
Sergei Golubchik
41c760b121 merge 2014-02-28 10:00:31 +01:00
Alexander Barkov
57cdc561fc Fixing AIX compilation failires 2014-02-27 19:44:00 +04:00
Sergei Golubchik
0dc23679c8 10.0-base merge 2014-02-26 15:28:07 +01:00
Sergei Golubchik
0b9a0a3517 5.5 merge 2014-02-25 16:04:35 +01:00
Sergey Vojtovich
d12c7adf71 MDEV-5314 - Compiling fails on OSX using clang
This is port of fix for MySQL BUG#17647863.

revno: 5572
revision-id: jon.hauglid@oracle.com-20131030232243-b0pw98oy72uka2sj
committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
timestamp: Thu 2013-10-31 00:22:43 +0100
message:
  Bug#17647863: MYSQL DOES NOT COMPILE ON OSX 10.9 GM

  Rename test() macro to MY_TEST() to avoid conflict with libc++.
2014-02-19 14:05:15 +04:00
Murthy Narkedimilli
075a2fb716 Updated/added copyright header. Added line "use is subject to license terms"
to copyright header.
2014-02-17 18:19:04 +05:30
Murthy Narkedimilli
42bfa90874 Updated/added copyright header. Added line "use is subject to license terms"
to copyright header.
2014-02-17 18:19:04 +05:30
Sergei Golubchik
95f4bf1857 MDEV-5613 m_string.h exports generic function names without a namespace prefix, like str2int
don't include m_string. in my_valgrind.h
2014-02-17 11:09:57 +01:00
Sergei Golubchik
84651126c0 MySQL-5.5.36 merge
(without few incorrect bugfixes and with 1250 files where only a copyright year was changed)
2014-02-17 11:00:51 +01:00
unknown
dd93ec5633 Merge MariaDB 10.0-base to 10.0. 2014-02-10 15:12:17 +01:00
unknown
fefdb576bb Merge of MDEV-4984, MDEV-4726, and MDEV-5636 into 10.0-base.
MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID.
    MDEV-4726: Race in mysql-test/suite/rpl/t/rpl_gtid_stop_start.test
    MDEV-5636: Deadlock in RESET MASTER
2014-02-10 12:39:26 +01:00
unknown
4e6606acad MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID.
MASTER_GTID_WAIT() is similar to MASTER_POS_WAIT(), but works with a
GTID position rather than an old-style filename/offset.

@@LAST_GTID gives the GTID assigned to the last transaction written
into the binlog.

Together, the two can be used by applications to obtain the GTID of
an update on the master, and then do a MASTER_GTID_WAIT() for that
position on any read slave where it is important to get results that
are caught up with the master at least to the point of the update.

The implementation of MASTER_GTID_WAIT() is implemented in a way
that tries to minimise the performance impact on the SQL threads,
even in the presense of many waiters on single GTID positions (as
from @@LAST_GTID).
2014-02-07 19:15:28 +01:00
Murthy Narkedimilli
5ffe40022b Fixing the bug 18184414: WRONG COPYRIGHT TO FILE INCLUDE/MYSQL_VERSION.H.IN 2014-02-06 14:11:38 +05:30
Murthy Narkedimilli
92971b9b31 Fixing the bug 18184414: WRONG COPYRIGHT TO FILE INCLUDE/MYSQL_VERSION.H.IN 2014-02-06 14:11:38 +05:30
Michael Widenius
10001c8e4f Automatic merge 2014-02-05 19:23:11 +02:00
Sergei Golubchik
5475cc7765 merge 2014-02-04 10:49:44 +01:00
Alexander Barkov
42af7a27f1 Removing "#include <sys/timeb.h>" from my_global.h,
which has been removed earlier, but somehow got into the sources again.

This file is not really needed, and it prints warnings
"sys/timeb.h is deprecated" for every file when compiling on FreeBSD.
2014-02-04 12:05:00 +04:00
Sergei Golubchik
72c20282db 10.0-base merge 2014-02-03 15:22:39 +01:00
Sergei Golubchik
fa11d613cf MySQL WL#5522 - InnoDB transportable tablespaces.
Cleanups:
* remove unused HA_EXTRA_EXPORT (can be added later if needed, e.g. for Aria)
* clarify the meaning of HA_CAN_EXPORT
* make all engines that support EXPORT to announce it
* reduce code duplication
2014-02-02 10:06:29 +01:00
Sergei Golubchik
27d45e4696 MDEV-5574 Set AUTO_INCREMENT below max value of column.
Update InnoDB to 5.6.14
Apply MySQL-5.6 hack for MySQL Bug#16434374
Move Aria-only HA_RTREE_INDEX from my_base.h to maria_def.h (breaks an assert in InnoDB)
Fix InnoDB memory leak
2014-02-01 09:33:26 +01:00
Sergei Golubchik
59d9d08e2b 5.5 merge 2014-02-01 00:54:03 +01:00
Sergei Golubchik
37d240ecf9 MySQL-5.5.35 merge 2014-01-22 15:29:36 +01:00
Michael Widenius
04bee0af2e Fix for MDEV-5547: Bad error message when moving very old .frm files to MariaDB 5.5.
mysql_upgrade --help now also prints out --default options and variable values.
mysql_upgrade now prints permission errors.
mysql_upgrade doesn't print some non essential info if --silent is used.
Added handler error message about incompatible versions
Fixed that mysqlbug and mysql_install_db have the executable flag set.
Removed executable flag for some non executable files.
Changed in mysql_install_db askmonty.org to mariadb.com.
Ensured that all client executables prints --default options the same way.
Allow REPAIR ... USE_FRM for old .frm files if the are still compatible.
Extended shown error for storage engine messages.


client/mysql.cc:
  print_defaults() should be first (as in all other programs)
client/mysql_upgrade.c:
  --help now also prints out --default options and variable values
  Print out error if wrong permissions
  Don't print info if --silent
client/mysqladmin.cc:
  print_defaults() should be first (as in all other programs)
client/mysqlbinlog.cc:
  Added print_defaults() to --help
client/mysqlcheck.c:
  Added empty line in --help
client/mysqlimport.c:
  Added empty line in --help
client/mysqlshow.c:
  Made --help compatible
client/mysqlslap.c:
  Made --help compatible
client/mysqltest.cc:
  Added print_defaults() to --help
include/handler_ername.h:
  Added handler error message
include/my_base.h:
  Added handler error message
mysql-test/r/mysql_upgrade.result:
  Updated results
mysql-test/r/repair.result:
  Added test case for better error messages
mysql-test/std_data/host_old.MYD:
  Added test case for better error messages
mysql-test/std_data/host_old.MYI:
  Added test case for better error messages
mysql-test/std_data/host_old.frm:
  Added test case for better error messages
mysql-test/t/repair.test:
  Added test case for better error messages
mysys/my_handler_errors.h:
  Added handler error message
scripts/CMakeLists.txt:
  Fixed that mysqlbug and mysql_install_db have the executable flag set
scripts/mysql_install_db.sh:
  askmonty.org -> mariadb.com
sql/ha_partition.cc:
  Sometimes table_type() can be called for errors even if partition didn't manage to open any files
sql/handler.cc:
  Write clear text for not handled, but defined error messages.
sql/share/errmsg-utf8.txt:
  Extended shown error for storage engine messages
sql/sql_admin.cc:
  Allow REPAIR ... USE_FRM for old .frm files if the are still compatible
storage/myisam/ha_myisam.cc:
  Use new error message
2014-01-22 15:16:57 +02:00
Venkata Sidagam
ff6b117c36 Bug COLLATIONS WITH CONTRACTIONS BUFFER-OVERFLOW THEMSELVES IN THE FOOT
Description: A typo in create_tailoring() causes the "contraction_flags" to be written
into cs->contractions in the wrong place. This causes two problems:
(1) Anyone relying on `contraction_flags` to decide "could this character be
part of a contraction" is 100% broken.
(2) Anyone relying on `contractions` to determine the weight of a contraction
is mostly broken

Analysis: When we are preparing the contraction in create_tailoring(), we are corrupting the 
cs->contractions memory location which is supposed to store the weights(8k) + contraction information(256 bytes). We started storing the contraction information after the 4k location. This is because of logic flaw in the code.

Fix: When we create the contractions, we need to calculate the contraction with (char*) (cs->contractions + 0x40*0x40) from ((char*) cs->contractions) + 0x40*0x40. This makes the "cs->contractions" to move to 8k bytes and stores the contraction information from there. Similarly when we are calculating it for like range queries we need to calculate it from the 8k bytes onwards, this can be done by changing the logic to (const char*) (cs->contractions + 0x40*0x40). And for ucs2 charsets we need to modify the my_cs_can_be_contraction_head() and my_cs_can_be_contraction_tail() to point to 8k+ locations.
2014-01-11 14:48:29 +05:30
Venkata Sidagam
ff06148679 Bug COLLATIONS WITH CONTRACTIONS BUFFER-OVERFLOW THEMSELVES IN THE FOOT
Description: A typo in create_tailoring() causes the "contraction_flags" to be written
into cs->contractions in the wrong place. This causes two problems:
(1) Anyone relying on `contraction_flags` to decide "could this character be
part of a contraction" is 100% broken.
(2) Anyone relying on `contractions` to determine the weight of a contraction
is mostly broken

Analysis: When we are preparing the contraction in create_tailoring(), we are corrupting the 
cs->contractions memory location which is supposed to store the weights(8k) + contraction information(256 bytes). We started storing the contraction information after the 4k location. This is because of logic flaw in the code.

Fix: When we create the contractions, we need to calculate the contraction with (char*) (cs->contractions + 0x40*0x40) from ((char*) cs->contractions) + 0x40*0x40. This makes the "cs->contractions" to move to 8k bytes and stores the contraction information from there. Similarly when we are calculating it for like range queries we need to calculate it from the 8k bytes onwards, this can be done by changing the logic to (const char*) (cs->contractions + 0x40*0x40). And for ucs2 charsets we need to modify the my_cs_can_be_contraction_head() and my_cs_can_be_contraction_tail() to point to 8k+ locations.
2014-01-11 14:48:29 +05:30
Murthy Narkedimilli
77d039ad42 updating the current copyright year which reflects in the MySQL welcome message. 2014-01-09 16:07:14 +05:30