Commit graph

176522 commits

Author SHA1 Message Date
Marko Mäkelä
70a9b12de9 Silence -Wimplicit-fallthrough 2018-01-23 18:08:55 +02:00
Vicențiu Ciorbaru
cd33250d2a 5.6.38-83.0 2018-01-23 18:04:34 +02:00
Vicențiu Ciorbaru
3dfe148074 5.6.39 2018-01-23 17:43:37 +02:00
Jan Lindström
f4d798635e
Merge pull request from grooverdan/10.1-MDEV-13789-freebsd-wsrep-sst-xtrabackup
MDEV-13789: FreeBSD wsrep_sst_xtrabackup-v2 - find compatibilty +lsof
2018-01-23 15:53:58 +02:00
Oleksandr Byelkin
ba8d0fa700 MDEV-14786: Server crashes in Item_cond::transform on 2nd execution of SP querying from a view
MDEV-14957: JOIN::prepare gets unusable "conds" as argument

Do not touch merged derived (it is irreversible)

Fix first argument of in_optimizer for calls possible before fix_fields()
2018-01-23 13:42:41 +01:00
Oleksandr Byelkin
11408a69ad Fix Item tree changes/rollback debug print 2018-01-23 13:42:41 +01:00
Oleksandr Byelkin
a4663af05c MDEV-7533: COLUMN_JSON() doesn't escape control characters in string values
escape all charecters less or equal 0x1F (control symbols)
(shorter sequence are not used to make code simple, long encoding is always legal according to the rfc4627)
2018-01-23 13:06:39 +01:00
Sachin Setiya
94da1cb4a6 MDEV-14586 Assertion `0' failed in retrieve_auto_increment ...
Problem:-
 If we create table using myisam/aria then this crashes the server.
  CREATE TABLE t1(a bit(1), b int auto_increment , index(a,b));
  insert into t1 values(1,1);
 Or this query
  CREATE TABLE t1 (b BIT(1), pk INTEGER AUTO_INCREMENT PRIMARY KEY);
  ALTER TABLE t1 ADD INDEX(b,pk);
  INSERT INTO t1 VALUES (1,b'1');
  ALTER TABLE t1 DROP PRIMARY KEY;

Reason:-
 The reason for this is
 1st- find_ref_key() finds what key an auto_increment field belongs to by
  comparing key_part->offset and field->ptr. But BIT fields might have
  zero length in the record, so a key might have many key parts with the
  same offset. That is, comparing offsets cannot uniquely identify the
  correct key part.
 2nd- Since next_number_key_offset is zero it myisam/aria will think that
  auto_increment is in first part of key.
 3nd- myisam/aria will call retrieve_auto_key which will see first key_part
  field as a bit field and call assert(0)

Solution:-
  Many key parts might have the same offset, but BIT fields do not
  support auto_increment. So, we can skip all key parts over BIT fields,
  and then comparing offsets will be unambiguous.
2018-01-23 17:29:58 +05:30
Daniel Black
cc3155415e MDEV-5510: Replace MySQL -> MariaDB in init scripts 2018-01-23 15:44:31 +04:00
Karim Geiger
701c7e777f Fix error message typo 2018-01-23 15:26:54 +04:00
Daniel Black
9ee372736f mysql_install_db: correct hosting/source/maillist information 2018-01-23 15:03:30 +04:00
Daniel Black
c98906e4fe mysql_install_db: correct --skip-grant-tables help 2018-01-23 15:03:30 +04:00
Eugene Kosov
3532a421f6 fix build for recent clang
/home/kevg/work/mariadb/sql/sql_partition.cc:286:47: error: cannot initialize a parameter of type 'HA_CREATE_INFO *' (aka 'st_ha_create_information *') with an rvalue of type 'ulonglong' (aka 'unsigned long long')
                                              (ulonglong)0, (uint)0);
                                              ^~~~~~~~~~~~
/home/kevg/work/mariadb/sql/partition_info.h:281:72: note: passing argument to parameter 'info' here
  bool set_up_defaults_for_partitioning(handler *file, HA_CREATE_INFO *info,
                                                                       ^
2018-01-23 14:45:37 +04:00
Vicențiu Ciorbaru
a04b07eb34 Fix TokuDB Not building
We don't check for DLSYM in CMake, check for DLOPEN instead.
2018-01-23 00:03:41 +02:00
Vladislav Vaintroub
30b1fbda28 MDEV-14746 : read [mariabackup] section from config file. 2018-01-22 20:16:19 +00:00
Vladislav Vaintroub
054051bb76 MDEV-14150 - backup should fail early if rsync is missing
check availability of rsync utility early , when starting backup with
--rsync. Fail if it is not there.
2018-01-22 20:01:03 +00:00
Sergei Golubchik
ea78c5744b MDEV-13988 connect.drop-open-error fails
PCOLRES::Length is the length in characters, not in bytes
(because it's printed as length in "VARCHAR(N)").
So convert it into characters using cs->mbmaxlen.
2018-01-22 20:26:34 +01:00
Sergei Golubchik
8539e4b1b6 improve ASAN instrumentation: clang
translate clang __has_feature to gcc macros
2018-01-22 16:36:39 +01:00
Vladislav Vaintroub
e30cdb68e5 mariabackup : improve help text 2018-01-22 15:10:56 +00:00
Marko Mäkelä
431607237d MDEV-12173 "Error: trying to do an operation on a dropped tablespace"
InnoDB is issuing a 'noise' message that is not a sign of abnormal
operation. The only issuers of it are the debug function
lock_rec_block_validate() and the change buffer merge.
While the error should ideally never occur in transactional locking,
we happen to know that DISCARD TABLESPACE and TRUNCATE TABLE and
possibly DROP TABLE are breaking InnoDB table locks.

When it comes to the change buffer merge, the message simply is useless
noise. We know perfectly well that a tablespace can be dropped while a
change buffer merge is pending. And the code is prepared to handle that,
which is demonstrated by the fact that whenever the message was issued,
InnoDB did not crash.

fil_inc_pending_ops(): Remove the parameter print_err.
2018-01-22 16:58:13 +02:00
Vicențiu Ciorbaru
b20c3dc664 MDEV-14715: Assertion `!table || (!table->read_set... failed in Field_num::val_decimal
The assertion failure was caused by an incorrectly set read_set for
functions in the ORDER BY clause in part of a union, when we are using
a mergeable view and the order by clause can be skipped (removed).

An order by clause can be skipped if it's part of one part of the UNION as
the result set is not meaningful when multiple SELECT queries are UNIONed. The
server is aware of this optimization and tries to remove the order by
clause before JOIN::prepare. The problem is that we need to throw an
error when the ORDER BY clause contains invalid columns. To do this, we
attempt resolving the ORDER BY expressions, then subsequently drop them
if resolution succeeded. However, ORDER BY resolution had the side
effect of adding the expressions to the all_fields list, which is used
to construct temporary tables to store the result. We may be ignoring
the ORDER BY statement, but the tmp table still tried to compute the
values for the expressions, even if the columns are never used.

The assertion only shows itself if the order by clause contains members
which were not previously in the select list, and are part of a
function.

There is an additional question as to why this only manifests when using
VIEWS and not when using a regular table. The difference lies with the
"reset" of the read_set for the temporary table during
SELECT_LEX::update_used_tables() in JOIN::optimize(). The changes
introduced in fdf789a7ea cleared the
read_set when a mergeable view is encountered in the TABLE_LIST
defintion.

Upon initial order_list resolution, the table's read_set is updated
correctly. JOIN::optimize() will only reset the read_set if it
encounters a VIEW. Since we no longer have ORDER BY clause in
JOIN::optimize() we never get to correctly update the read_set again.

Other relevant commit by Timour, which first introduced the order
resolution when we "can_skip_sort_order":
883af99e7d

Solution:
Don't add the resolved ORDER BY elements to all_fields. We only resolve
them to check if an error should be returned for the query. Ignore them
completely otherwise.
2018-01-22 15:39:42 +02:00
Vicențiu Ciorbaru
6d826e3d7e Remove commented out code post merge fix in 2011 2018-01-22 15:39:42 +02:00
Sergei Golubchik
03eb15933d improve ASAN instrumentation: InnoDB/XtraDB 2018-01-22 11:39:54 +01:00
Sergei Golubchik
d9c460b84e Finally! Make './mtr --valgrind-mysqld --gdb' to work.
It has its limitations, e.g. it assumes that there's only one
gdb and only one valgrind process is running. And a hard-coded
one-second delay might be too short for slow machines.

Still, it's better than "doesn't work at all"
2018-01-22 11:39:54 +01:00
Sergei Golubchik
f2408e7e6a Free memory in unit tests. Makes ASAN happier. 2018-01-22 11:39:54 +01:00
Sergei Golubchik
36eb0b7a55 improve ASAN instrumentation: table->record[0]
instrument table->record[0], table->record[1] and share->default_values.

One should not access record image beyond share->reclength, even
if table->record[0] has some unused space after it (functions that
work with records, might get a copy of the record as an argument,
and that copy - not being record[0] - might not have this buffer space
at the end). See b80fa4000d and 444587d8a3
2018-01-22 11:39:54 +01:00
Sergei Golubchik
fa331acefd improve ASAN instrumentation: mtr 2018-01-22 11:39:54 +01:00
Sergei Golubchik
dc28b6d180 improve ASAN instrumentation: MEM_ROOT
more complete TRASH-ing of memroots
2018-01-22 11:39:54 +01:00
Sergei Golubchik
a966d422ca improve ASAN instrumentation: TRASH
mark freed memory as not accessible, not merely undefined
2018-01-22 11:39:54 +01:00
Sergei Golubchik
22ae3843db Correct TRASH() macro usage
TRASH was mapped to TRASH_FREE and was supposed to be used for memory
that should not be accessed anymore, while TRASH_ALLOC() is to be
used for uninitialized but to-be-used memory.

But sometimes TRASH() was used in the latter sense.

Remove TRASH() macro, always use explicit TRASH_ALLOC() or TRASH_FREE().
2018-01-22 11:39:54 +01:00
Sergei Golubchik
204cb85aab Fix compilation without dlopen 2018-01-22 11:39:54 +01:00
Marko Mäkelä
906ce0962d MDEV-7049 MySQL#74585 - InnoDB: Failing assertion: *mbmaxlen < 5 in file ha_innodb.cc line 1904
InnoDB limited the maximum number of bytes per character to 4.
But, the filename character set that was introduced in MySQL 5.1
uses up to 5 bytes per character.

To allow InnoDB tables to be created with wider characters, let
us split the mbminmaxlen fields into mbminlen, mbmaxlen, and increase
the limit to 7 bytes per character. This will increase the payload size
of dtype_t and dict_col_t by one bit. The storage size will be unchanged
(54 bits and 77 bits will use the same number of bytes as the
previous sizes 53 and 76 bits).
2018-01-22 11:18:10 +02:00
Vicențiu Ciorbaru
6c60c809bb Add dummy defintion for Dl_info in case we're missing dladdr 2018-01-19 18:05:24 +02:00
Daniel Bartholomew
17f64b362a bump the VERSION 2018-01-19 11:01:32 -05:00
Vicențiu Ciorbaru
26e5f9dda1 MDEV-14229: Stack trace is not resolved for shared objects
Resolving a stacktrace including functions in dynamic libraries requires
us to look inside the libraries for the symbols. Addr2line needs to be
started with the correct binary for each address on the stack. To do this,
figure out which library it is using dladdr, then if the addr2line
binary was started with a different binary, fork it again with the
correct one.

We only have one addr2line process running at any point during the
stacktrace resolving step. The maximum number of forks for addr2line should
generally be around 6.

One for server stacktrace code, one for plugin code, one when going back
into server code, one for pthread library, one for libc, one for the
_start function in the server. More can come up if plugin calls server
function which goes back to a plugin, etc.
2018-01-19 16:11:34 +02:00
Varun Gupta
a7a4519a40 MDEV-14241: Server crash in key_copy / get_matching_chain_by_join_key or valgrind warnings
In this case we were using the optimization derived_with_keys but we could not create a key
because the length of the key was greater than the max allowed(MI_MAX_KEY_LENGTH).
To do the join we needed to create a hash join key instead, but in the explain output it
showed that we were still referring to derived keys which were created but not used.
2018-01-19 13:29:31 +05:30
Igor Babaev
4f96b401d9 Fixed mdev-14960 [ERROR] mysqld got signal 11 with join_buffer and join_cache
In the function JOIN::shrink_join_buffers the iteration over joined
tables was organized in a wrong way. This could cause a crash if
the optimizer chose to materialize a semi-join that used join caches
for which the sizes must be adjusted.
2018-01-18 09:57:25 -08:00
Sergei Golubchik
fafdac3365 Merge branch 'merge/merge-xtradb-5.5' into 5.5 2018-01-18 17:56:28 +01:00
Sergei Golubchik
2d52d3c1bf Merge branch 'mysql/5.5' into 5.5 2018-01-18 17:54:48 +01:00
Sergei Golubchik
8aff418ec8 crash with too long index comments 2018-01-18 17:50:34 +01:00
Sergei Golubchik
fa42df7569 compiler warning: my_printf_error() supports printf format extensions 2018-01-18 17:50:34 +01:00
Sergei Golubchik
0d59b1db83 cleanup 2018-01-18 17:50:34 +01:00
Vladislav Vaintroub
2fad31a1cf MDEV-14446 followup
Fix WinUIDialogBmp.jpg to use correct dimensions
2018-01-18 16:42:11 +00:00
Vladislav Vaintroub
a73cb82db0 MDEV-14446 Windows installer still uses the old brown logo
Use new grey logo.
2018-01-18 16:15:18 +00:00
Daniel Black
be83785d73 MDEV-13789: FreeBSD wsrep_sst_xtrabackup-v2 - find compatibilty +lsof
Based off  by angeloudy <angeloudy@yahoo.com> and
Tao Zhou <taozhou@ip-179.ish.com.au>
2018-01-18 22:06:17 +11:00
Marko Mäkelä
5e87f49a99 Make row_mysql_table_id_reassign() static 2018-01-18 09:29:49 +02:00
Sergei Golubchik
85a5e58d71 5.5.58-38.10 2018-01-17 17:28:33 +01:00
Daniel Black
c73b4b1698 wsrep_sst_mysqldump: enforce a minimum version only 2018-01-17 20:16:59 +11:00
Sergei Golubchik
b80fa4000d bug: ha_heap was unilaterally increasing reclength
MEMORY engine needs the record length to be at least sizeof(void*),
because it stores a pointer there (linking deleted records into a list).
So when the reclength is less than sizeof(void*), it's set to sizeof(void*).
That is done inside heap_create(), and the upper layer doesn't know
that the engine writes beyond share->reclength.

While it's usually safe (in-memory record size is rounded up to
sizeof(double), so even if share->reclength is too small,
share->rec_buff_len is not), it could cause problems in the code that
copies records and expects them to fix in share->reclength,
e.g. in partitioning.
2018-01-16 23:31:29 +01:00
Sergei Golubchik
444587d8a3 BIT field woes
* get_rec_bits() was always reading two bytes, even if the
  bit field contained only of one byte
* In various places the code used field->pack_length() bytes
  starting from field->ptr, while it should be field->pack_length_in_rec()
* Field_bit::key_cmp and Field_bit::cmp_max passed field_length as
  an argument to memcmp(), but field_length is the number of bits!
2018-01-16 23:29:48 +01:00