Commit graph

73474 commits

Author SHA1 Message Date
Marko Mäkelä
9fe784ff7e Merge 10.8 into 10.9 2022-06-15 10:01:51 +03:00
Marko Mäkelä
813986a647 Merge 10.7 into 10.8 2022-06-14 16:19:29 +03:00
Marko Mäkelä
ddf511c44d Merge 10.6 into 10.7 2022-06-14 10:17:36 +03:00
Marko Mäkelä
1f1fa7e09c Merge 10.5 into 10.6 2022-06-14 09:49:47 +03:00
Nayuta Yanagisawa
06e9ce798c MDEV-26127 Assertion `err != DB_DUPLICATE_KEY' failed or InnoDB: Failing assertion: id != 0 on ALTER ... REBUILD PARTITION
During rebuild of partition, the partitioning engine calls
alter_close_table(), which does not unlock and close some table
instances of the target table.
Then, the engine fails to rename partitions because there are table
instances that are still locked.

Closing all the table instance of the target table fixes the bug.
2022-06-13 23:44:59 +09:00
Marko Mäkelä
6dea701e0f Merge 10.8 into 10.9 2022-06-09 14:53:34 +03:00
Marko Mäkelä
0af9346079 Merge 10.7 into 10.8 2022-06-09 14:37:53 +03:00
Marko Mäkelä
fe75e5e5b1 Merge 10.6 into 10.7 2022-06-09 14:11:43 +03:00
Marko Mäkelä
e11b82f8f5 Merge 10.5 into 10.6 2022-06-09 13:34:52 +03:00
Marko Mäkelä
a9d0bb12e6 Merge 10.4 into 10.5 2022-06-09 12:22:55 +03:00
Marko Mäkelä
c89e3b70a7 Merge 10.3 into 10.4 2022-06-09 11:53:46 +03:00
Daniel Lewart
2cd1edfc21 MDEV-25577 mariadb-tzinfo-to-sql generates superfluous warnings
The zoneinfo directory is littered with non-timezone information files.

These frequently contain extensions, not present in real timezone files.

Alo leapseconds is frequently there and is not a timezone file.
2022-06-09 13:20:37 +10:00
Roman Nozdrin
e74858c8a8 MCOL-5114 Removing ctor specialization b/c it violates c++20 syntax needed in ColumnStorew 2022-06-09 11:18:54 +10:00
chansuke
960f0344a2 MDEV-25273: fix typo (s/strucures/structures/) 2022-06-08 13:37:35 +10:00
Monty
3d241eb948 Improve error reporting in Aria
This patch fixes the following issues in Aria error reporting in case
of read errors & crashed tables:
- Added the table name to the most error messages, including in case of
  read errors or when encrypting/decrypting a table. The format for
  error messages was changed sligtly to accomodate logging of errors
  from lower level routines.
- If we got an read error from storage (hard disk, ssd, S3 etc) we only
  reported 'table is crashed'. Now the error number from the storage
  is reported.
- Added checking of read failure from records_in_range()
- Calls to ma_set_fatal_error() did not inform the SQL level of
  errors (to not spam the user with multiple error messages).
  Now the first error message and any fatal error messages are reported
  to the user.
2022-06-07 20:43:11 +03:00
Michael Widenius
31811cf81d Make join->key_dependent up to date for derived tables
Main-author: Sergei Petrunia
2022-06-07 20:43:11 +03:00
Michael Widenius
432a4ebe5c Improve table pruning in optimizer with up to date key_dependent map
Part of:
MDEV-28073 Slow query performance in MariaDB when using many tables

s->key_dependent has a list of tables that are compared with key fields
in the current table.  However it does not take into account if a key
field could be resolved by another table.
This is because MariaDB expands 'join_tab->keyuse' to include all generated
comparisons.
For example:
SELECT * from t1,t2,t3 where t1.key=t2.key and t2.key=t3.key
In this case keyuse for t1 includes t2.key and t3.key and key_dependent
contains 't2.map | t3.map'
If we in best_extension_by_limited_search() consider t2,t1 then t1's
key is fully defined, but we cannot do any prune of plans as
s->key_dependent indicates that t3 is still needed.

Fixed by calculating in best_access_patch the current key_dependent map
of tables that is needed to satisfy all keys. This allows us to prune
more bad plans earlier as soon as all keys can be used.

We also set key_dependent to 0 if we found an EQ_REF key, as this an
optimal key for the table and there is no reason to check more keys.
2022-06-07 20:43:11 +03:00
Michael Widenius
64f24b776d greedy_search() and best_extension_by_limited_search() scrambled table order
best_extension_by_limited_search() assumes that tables should be sorted
according to size to be able to quickly disregard bad plans. However the
current usage of swap_variables() will change the table order to a not
sorted one for the next recursive call. This breaks the assumtion and
causes performance issues when using many tables (we have to examine
many more plans).

This patch fixes this by ensuring that the original table order is kept
for the not yet used tables when best_extension_by_limited_search() is
called.

This was done by always calling swap_variables() for each table and
restoring the original table order at exit.

Some test changed:
- In a majority of the test the change was that two "identical tables"
  where swapped and the optimzer is now using the first/smaller table
- In few test the table order was changed. The new plan looks identical
  or slighly better than the original.
2022-06-07 20:43:10 +03:00
Sergei Petrunia
f0ea7f7f33 MDEV-28749: restore_prev_nj_state() doesn't update cur_sj_inner_tables correctly
(Try 2)

The code that updates semi-join optimization state for a join order prefix
had several bugs. The visible effect was bad optimization for FirstMatch or
LooseScan strategies: they either weren't considered when they should have
been, or considered when they shouldn't have been.

In order to hit the bug, the optimizer needs to consider several different
join prefixes in a certain order. Queries with "obvious" query plans which
prune all join orders except one are not affected.

Internally, the bugs in updates of semi-join state were:
1. restore_prev_sj_state() assumed that
  "we assume remaining_tables doesnt contain @tab"
  which wasn't true.
2. Another bug in this function: it did remove bits from
   join->cur_sj_inner_tables but never added them.
3. greedy_search() adds tables into the join prefix but neglects to update
   the semi-join optimization state. (It does update nested outer join
   state, see this call:
     check_interleaving_with_nj(best_table)
   but there's no matching call to update the semi-join state.
   (This wasn't visible because most of the state is in the POSITION
    structure which is updated. But there is also state in JOIN, too)

The patch:
- Fixes all of the above
- Adds JOIN::dbug_verify_sj_inner_tables() which is used to verify the
  state is correct at every step.
- Renames advance_sj_state() to optimize_semi_joins().
  = Introduces update_sj_state() which ideally should have been called
    "advance_sj_state" but I didn't reuse the name to not create confusion.
2022-06-07 20:43:10 +03:00
Monty
46c4fd45c3 Fixed cost calculation for SELECT STRAIGHT_JOIN
Main fix was replacing read_time+= with read_time

I also did updated the 'identical' code in optimize_straight_join) and
best_extension_by_limited_search() to make them eaiser to compare.

Reviewer: Sergei Petrunia <sergey@mariadb.com>
2022-06-07 20:43:10 +03:00
Monty
e240e8d062 removed some compiler warnings 2022-06-07 20:43:10 +03:00
Sergei Petrunia
19c721631e MDEV-28749: restore_prev_nj_state() doesn't update cur_sj_inner_tables correctly
(Try 2) (Cherry-pick back into 10.3)

The code that updates semi-join optimization state for a join order prefix
had several bugs. The visible effect was bad optimization for FirstMatch or
LooseScan strategies: they either weren't considered when they should have
been, or considered when they shouldn't have been.

In order to hit the bug, the optimizer needs to consider several different
join prefixes in a certain order. Queries with "obvious" query plans which
prune all join orders except one are not affected.

Internally, the bugs in updates of semi-join state were:
1. restore_prev_sj_state() assumed that
  "we assume remaining_tables doesnt contain @tab"
  which wasn't true.
2. Another bug in this function: it did remove bits from
   join->cur_sj_inner_tables but never added them.
3. greedy_search() adds tables into the join prefix but neglects to update
   the semi-join optimization state. (It does update nested outer join
   state, see this call:
     check_interleaving_with_nj(best_table)
   but there's no matching call to update the semi-join state.
   (This wasn't visible because most of the state is in the POSITION
    structure which is updated. But there is also state in JOIN, too)

The patch:
- Fixes all of the above
- Adds JOIN::dbug_verify_sj_inner_tables() which is used to verify the
  state is correct at every step.
- Renames advance_sj_state() to optimize_semi_joins().
  = Introduces update_sj_state() which ideally should have been called
    "advance_sj_state" but I didn't reuse the name to not create confusion.
2022-06-07 18:48:44 +03:00
Marko Mäkelä
ea1fbd0326 Merge 10.3 into 10.4 2022-06-07 15:55:32 +03:00
Marko Mäkelä
5a33a37682 Merge 10.8 into 10.9 2022-06-07 09:20:07 +03:00
Marko Mäkelä
57d4a242da Merge 10.7 into 10.8 2022-06-06 16:22:09 +03:00
Marko Mäkelä
7e39470e33 Merge 10.6 into 10.7 2022-06-06 14:56:20 +03:00
Alexander Barkov
477776bfed MDEV-28491 Uuid. "UPDATE/DELETE" not working "WHERE id IN (SELECT id FROM ..)"
This is a 10.7 version of the patch.
2022-06-03 20:14:41 +04:00
Marko Mäkelä
099b9202a5 MDEV-27697 fixup: Exclude debug code from non-debug builds 2022-06-03 10:47:34 +03:00
Marko Mäkelä
2f8d0af883 Merge 10.5 into 10.6 2022-06-02 17:39:13 +03:00
Marko Mäkelä
4b3c3e526e Merge 10.4 into 10.5 2022-06-02 16:51:13 +03:00
Marko Mäkelä
96f4b4a55b Merge 10.3 into 10.4 2022-06-02 16:34:17 +03:00
Marko Mäkelä
600751e769 Merge 10.7 into 10.8 2022-06-02 08:01:17 +03:00
Marko Mäkelä
712b443a3c Merge 10.6 into 10.7 2022-06-02 07:48:30 +03:00
Rucha Deodhar
a61603562e MDEV-25875: JSON_TABLE: extract document fragment into JSON column
Fixup
2022-05-31 12:09:29 +05:30
Alexey Botchkov
a9f6abedde MDEV-25875: JSON_TABLE: extract document fragment into JSON column
Accept JSON values for the JSON fields.
2022-05-31 12:09:11 +05:30
Alexey Botchkov
6b6d745b9e let numeric in the DEMAULT. 2022-05-31 12:08:54 +05:30
Monty
131c318b16 Remove compiler warning about unused variables 2022-05-30 17:26:48 +03:00
Masashi Tomooka
f7137a619f
MDEV-28599 EXCHANGE PARTITION on view causes ER_CHECK_NO_SUCH_TABLE instead of ER_WRONG_OBJECT
ER_CHECK_NO_SUCH_TABLE was raised because a view does not have
the corresponding TABLE instance connected to TABLE_LIST and the
server interprets the absence as the absence of the table itself.

To fix the problem, we add a check to ensure that the target table
to be swapped with a partition is not a view.

Reviewed by: Nayuta Yanagisawa
2022-05-30 19:28:44 +09:00
mkaruza
ebbd5ef6e2 MDEV-27862 Galera should replicate nextval()-related changes in sequences with INCREMENT <> 0, at least NOCACHE ones with engine=InnoDB
Sequence storage engine is not transactionl so cache will be written in
stmt_cache that is not replicated in cluster. To fix this replicate
what is available in both trans_cache and stmt_cache.

Sequences will only work when NOCACHE keyword is used when sequnce is
created. If WSREP is enabled and we don't have this keyword report error
indicting that sequence will not work correctly in cluster.

When binlog is enabled statement cache will be cleared in transaction
before COMMIT so cache generated from sequence will not be replicated.
We need to keep cache until replication.

Tests are re-recorded because of replication changes that were
introducted with this PR.

Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2022-05-30 12:43:52 +03:00
Jan Lindström
c8fabbed42 MDEV-20627 : Galera 4 not able to report proper wsrep_incoming_addresses
wsrep_server_incoming_address function always returned value of the
wsrep_node_incoming_address even when actual incoming address
was resolved to inc_addr variable. Fixed by returning inc_addr
if it does contain incoming address.
2022-05-30 12:43:46 +03:00
Michal Schorm
6ec17142dc Fix the FSF address to match the current one in: http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt 2022-05-27 15:55:49 +10:00
kkz
f85d488ad2 remove obsolete fix_session_vcol_expr{,_for_read} function declarations 2022-05-26 09:28:22 +10:00
Alexander Barkov
e9adc3959e A cleanup for MDEV-27896 Wrong result upon COLLATE latin1_bin CHARACTER SET latin1 on the table or the database level
Changing the error messages in a statement like this:

CREATE DATABASE db1
         COLLATE utf8mb4_bin
         CHARACTER SET utf8mb4
         CHARACTER SET latin1;

from
  COLLATION 'utf8mb4_bin' is not valid for CHARACTER SET 'latin1'

to a more expected:

  Conflicting declarations: 'CHARACTER SET utf8mb4' and 'CHARACTER SET latin1'

In order to do this:
- Adding a new type TYPE_CHARACTER_SET_COLLATE_EXACT into
  Lex_exact_charset_extended_collation_attrs_st

- Removing m_had_charset_exact from its descendant class
  Lex_extended_charset_extended_collation_attrs_st

Additional cleanup:
- Changing methods in Lex_exact_charset_extended_collation_attrs_st
  set_charset(), set_charset_collate_default(), set_charset_collate_binary()
  to get Lex_exact_charset instead CHARSET_INFO as a parameter,
  to guarantee that the argument is only CHARACTER SET and does not have
  any COLLATE clauses yet. This change is not directly related to
  the error message change.
2022-05-25 11:16:38 +04:00
Marko Mäkelä
1ace1075dc Merge 10.8 into 10.9 2022-05-25 08:52:21 +03:00
Marko Mäkelä
c2bae9c77f Merge 10.7 into 10.8 2022-05-25 08:38:17 +03:00
Marko Mäkelä
f00ac20b03 Merge 10.6 into 10.7 2022-05-24 09:49:48 +03:00
Alexander Barkov
208addf484 Main patch MDEV-27896 Wrong result upon COLLATE latin1_bin CHARACTER SET latin1 on the table or the database level
Also fixes
MDEV-27782 Wrong columns when using table level `CHARACTER SET utf8mb4 COLLATE DEFAULT`
MDEV-28644 Unexpected error on ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb3, DEFAULT CHARACTER SET utf8mb4
2022-05-24 09:36:15 +04:00
Norio Akagi
af869493b4 MDEV-27892 Improve an error message for foreign server exists
Improve and add more languages for the ERROR 1476: Foreign Server
already exists.
2022-05-24 10:57:13 +10:00
Daniel Black
a2bdd52835 Merge branch 10.5 into 10.6 2022-05-24 10:56:25 +10:00
Norio Akagi
99566fc894 MDEV-27892 Improve an error message for foreign server exists
Improve and add more languages for the ERROR 1476: Foreign Server
already exists.
2022-05-24 10:31:00 +10:00