1
0
mirror of https://github.com/MariaDB/server.git synced 2025-05-29 21:42:28 +03:00

2713 Commits

Author SHA1 Message Date
Marko Mäkelä
d28686ada6 Merge 10.4 into 10.5 2019-09-12 16:36:46 +03:00
Marko Mäkelä
60c04be659 Merge 10.3 into 10.4 2019-09-12 12:16:40 +03:00
Nikita Malyavin
f6a7730c45 MDEV-16490: It's possible to make a system versioned table without any versioning field
* do not allow versioned table to be without versioned (non-system) fields
* prohibit changing field versioning, when removing table versioning
* handle CREATE...SELECT as well
2019-09-09 20:14:47 +03:00
Marko Mäkelä
4081b7b27a Merge 10.4 into 10.5 2019-09-06 17:16:40 +03:00
Marko Mäkelä
780d2bb8a7 Merge 10.4 into 10.5 2019-09-06 14:25:20 +03:00
Sergei Golubchik
244f0e6dd8 Merge branch '10.3' into 10.4 2019-09-06 11:53:10 +02:00
Marko Mäkelä
537f8594a6 Merge 10.2 into 10.3 2019-09-04 17:52:04 +03:00
Alexander Barkov
7e08ac0b41 Merge 10.2 (up to commit ef00ac4c86daf3294c46a45358da636763fb0049) into 10.3 2019-09-04 10:19:58 +04:00
Sergei Golubchik
17ab02f4b0 cleanup: on update default now
* remove one level of virtual functions
* remove redundant checks
* remove an if() as the value is always known at compilation time

don't pretend that "DEFAULT expr" and "ON UPDATE DEFAULT NOW"
are "basically the same thing"
2019-09-03 20:34:30 +02:00
Alexander Barkov
ef00ac4c86 Part2: MDEV-18156 Assertion 0' failed or btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH
This patch allows the server to open old tables that have
"bad" generated columns (i.e. indexed virtual generated columns,
persistent generated columns) that depend on sql_mode,
for general things like SELECT, INSERT, DROP, etc.
Warning are issued in such cases.

Only these commands are now disallowed and return an error:
- CREATE TABLE introducing a "bad" generated column
- ALTER TABLE introducing a "bad" generated column
- CREATE INDEX introdicing a "bad" generated column
  (i.e. adding an index on a virtual generated column
   that depends on sql_mode).

Note, these commands are allowed:
- ALTER TABLE removing a "bad" generate column
- ALTER TABLE removing an index from a "bad" virtual generated column
- DROP INDEX removing an index from a "bad" virtual generated column
but only if the table does not have any "bad" columns as a result.
2019-09-03 09:51:35 +04:00
Oleksandr Byelkin
4f10d0918d Merge branch '10.3' into 10.4 2019-09-02 14:57:05 +02:00
Oleksandr Byelkin
b0ff5a6a73 Merge branch '10.2' into 10.3 2019-09-02 09:01:54 +02:00
Oleksandr Byelkin
14149d6c33 Merge remote-tracking branch 'connect/10.2' into 10.2 2019-08-30 16:52:43 +02:00
Marko Mäkelä
67ddb6507d Merge 10.4 into 10.5 2019-08-16 14:35:32 +03:00
Alexander Barkov
afe6eb499d Revert "MDEV-20342 Turn Field::flags from a member to a method"
This reverts commit e86010f909fb6b8c4ffd9d6df92991ac079e67e7.

Reverting on Monty's request, as this change makes merging
things from 10.5 to 10.2 much harder.
2019-08-14 20:27:00 +04:00
Marko Mäkelä
1d15a28e52 Merge 10.3 into 10.4 2019-08-14 18:06:51 +03:00
Alexander Barkov
e86010f909 MDEV-20342 Turn Field::flags from a member to a method 2019-08-14 13:33:01 +04:00
Alexander Barkov
c1599821a5 Merge remote-tracking branch 'origin/10.4' into 10.5 2019-08-13 23:49:10 +04:00
Marko Mäkelä
65d48b4a7b Merge 10.2 to 10.3 2019-08-13 19:28:51 +03:00
Marko Mäkelä
be33124c9d Merge 10.1 into 10.2 2019-08-12 18:25:35 +03:00
Sachin
284c72eacf MDEV-17614 INSERT on dup key update is replication unsafe
Problem:-
When mysql executes INSERT ON DUPLICATE KEY INSERT, the storage engine checks
if the inserted row would generate a duplicate key error. If yes, it returns
the existing row to mysql, mysql updates it and sends it back to the storage
engine.When the table has more than one unique or primary key, this statement
is sensitive to the order in which the storage engines checks the keys.
Depending on this order, the storage engine may determine different rows
to mysql, and hence mysql can update different rows.The order that the
storage engine checks keys is not deterministic. For example, InnoDB checks
keys in an order that depends on the order in which indexes were added to
the table. The first added index is checked first. So if master and slave
have added indexes in different orders, then slave may go out of sync.

Solution:-
Make INSERT...ON DUPLICATE KEY UPDATE unsafe while using stmt or mixed format
When there is more then one unique key.
Although there is two exception.
  1. Auto Increment key is not counted because Innodb will get gap lock for
    failed Insert and concurrent insert will get a next increment value. But if
    user supplies auto inc value it can be unsafe.
  2. Count only unique keys for which insertion is performed.

So this patch also addresses the bug id #72921
2019-08-09 19:36:56 +05:30
Oleksandr Byelkin
2792c6e7b0 Merge branch '10.3' into 10.4 2019-07-28 13:43:26 +02:00
Oleksandr Byelkin
d97342b6f2 Merge branch '10.2' into 10.3 2019-07-26 22:42:35 +02:00
Oleksandr Byelkin
cf8c2a3c3b Merge branch '10.1' into 10.2 2019-07-26 07:03:39 +02:00
Oleksandr Byelkin
ae476868a5 Merge branch '5.5' into 10.1 2019-07-25 13:27:11 +02:00
Oleksandr Byelkin
cc86a0bd11 MDEV-15572: view.test, server crash with --big-tables=1
Check that table is really opened before cleanup using handler.
2019-07-18 10:01:53 +02:00
Alexander Barkov
e6ff3f9d1c MDEV-20052 Add a MEM_ROOT pointer argument to Type_handler::make_xxx_field() 2019-07-12 06:58:51 +04:00
Eugene Kosov
d36c107a6b imporve clang build
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug

Maintainer mode makes all warnings errors. This patch fix warnings. Mostly about
deprecated `register` keyword.

Too much warnings came from Mroonga and I gave up on it.
2019-06-25 13:21:36 +03:00
Marko Mäkelä
49e5323dbd Merge 10.4 into 10.5 2019-06-20 09:22:10 +03:00
Marko Mäkelä
02979daab4 Merge 10.3 into 10.4 2019-06-19 10:49:00 +03:00
Marko Mäkelä
192aa295b4 Merge 10.2 into 10.3 2019-06-19 08:56:10 +03:00
Michael Widenius
c02d6164fb MDEV-19771 REPLACE on table with virtual_field can cause crash
Fixes also MDEV-17837

Problem was that we did not ignore warnings from virtual fields when
updated virtual fields for to-be-replaced row.
2019-06-15 14:54:21 +03:00
Alexander Barkov
d1d6fe9abf Using more of Sql_mode_save. Adding a similar class for THD::abort_on_warnings. 2019-05-28 10:26:08 +04:00
Oleksandr Byelkin
c07325f932 Merge branch '10.3' into 10.4 2019-05-19 20:55:37 +02:00
Marko Mäkelä
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
Marko Mäkelä
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
Vicențiu Ciorbaru
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
Vicențiu Ciorbaru
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
Marko Mäkelä
b132b8895e Merge 10.3 into 10.4 2019-05-05 10:23:14 +03:00
Marko Mäkelä
4d59f45260 Merge 10.2 into 10.3 2019-04-27 20:41:31 +03:00
Oleksandr Byelkin
4e01bc8c96 MDEV-16240: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase
Set table in row ID position mode before using this function.
2019-04-25 18:02:31 +02:00
Marko Mäkelä
b896f60a73 Fix -Wformat and -Wnonnull-compare for WSREP 2019-04-03 09:20:21 +03:00
Marko Mäkelä
514b305dfb Merge 10.3 into 10.4
The MDEV-17262 commit 26432e49d37a37d09b862bb49a021e44bdf4789c
was skipped. In Galera 4, the implementation would seem to require
changes to the streaming replication.

In the tests archive.rnd_pos main.profiling, disable_ps_protocol
for SHOW STATUS and SHOW PROFILE commands until MDEV-18974
has been fixed.
2019-03-20 10:41:32 +02:00
Sergei Golubchik
b64fde8f38 Merge branch '10.2' into 10.3 2019-03-17 13:06:41 +01:00
Sergei Golubchik
0508d327ae Merge branch '10.1' into 10.2 2019-03-15 21:00:41 +01:00
Sergei Golubchik
3d2d060b62 fix gcc 8 compiler warnings
There were two newly enabled warnings:
1. cast for a function pointers. Affected sql_analyse.h, mi_write.c
   and ma_write.cc, mf_iocache-t.cc, mysqlbinlog.cc, encryption.cc, etc

2. memcpy/memset of nontrivial structures. Fixed as:
* the warning disabled for InnoDB
* TABLE, TABLE_SHARE, and TABLE_LIST got a new method reset() which
  does the bzero(), which is safe for these classes, but any other
  bzero() will still cause a warning
* Table_scope_and_contents_source_st uses `TABLE_LIST *` (trivial)
  instead of `SQL_I_List<TABLE_LIST>` (not trivial) so it's safe to
  bzero now.
* added casts in debug_sync.cc and sql_select.cc (for JOIN)
* move assignment method for MDL_request instead of memcpy()
* PARTIAL_INDEX_INTERSECT_INFO::init() instead of bzero()
* remove constructor from READ_RECORD() to make it trivial
* replace some memcpy() with c++ copy assignments
2019-03-14 16:33:17 +01:00
Marko Mäkelä
2a791c53ad Merge 10.3 into 10.4 2019-03-06 09:00:52 +02:00
Marko Mäkelä
446b3ebdfc Merge 10.2 into 10.3
FIXME: Properly resolve conflicts between MDEV-18883
and MDEV-7742/MDEV-8305, and record the correct result for
main.log_slow
2019-03-05 12:56:05 +02:00
Marko Mäkelä
9835f7b80f Merge 10.1 into 10.2 2019-03-04 16:46:58 +02:00
Oleksandr Byelkin
f2e1451740 Merge branch '10.0' into 10.1 2019-03-01 15:52:06 +01:00