1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-18 23:03:28 +03:00
Commit Graph

2010 Commits

Author SHA1 Message Date
28c89b7151 Merge 10.4 into 10.5 2019-12-16 07:47:17 +02:00
a15234bf4b Merge branch '10.3' into 10.4 2019-12-09 15:09:41 +01:00
cef2b34f25 MDEV-18929 2nd execution of SP does not detect ER_VERS_NOT_VERSIONED
Wrong assertion condition. SYSTEM_TIME_ALL indicates that
vers_setup_conds() is done. In case FOR SYSTEM_TIME ALL is specified
in command the assertion passes but not checks anything.
2019-12-03 15:28:41 +03:00
8ed646f071 Merge 10.4 into 10.5 2019-12-02 13:35:54 +03:00
0b8b11b0b1 Merge 10.3 into 10.4 2019-12-02 12:51:53 +03:00
498a96a478 MDEV-20441 ER_CRASHED_ON_USAGE upon update on versioned Aria table
Turn read cache off for update and multi-update for versioned
table. no_cache is reinited on each TABLE open because it is
applicable for specific algorithms.

As a side fix vers_insert_history_row() honors vers_write setting.

Aria with row_format=fixed uses IO_CACHE of type READ_CACHE for
sequential read in update loop. When history row is inserted inside
this loop the cache misses it and fails with error.

TODO:

Currently maria_extra() does not support SEQ_READ_APPEND. Probably it
might be possible to use this type of cache.
2019-12-02 11:48:37 +03:00
e066723a41 MDEV-18973 CLIENT_FOUND_ROWS wrong in spider
Get count from last_used_con->info
Contributed by willhan at Tencent Games
2019-11-29 23:23:57 +09:00
0c05a2ed71 Merge 10.4 into 10.5 2019-11-25 17:24:09 +03:00
33f55789d3 MDEV-18727 improve DML operation of System Versioning (10.4)
UPDATE, DELETE: replace linear search of current/historical records
with vers_setup_conds().

Additional DML cases in view.test
2019-11-25 16:01:43 +03:00
bf58ec77a1 MDEV-18727 cleanup 2019-11-25 15:44:46 +03:00
0076dce2c8 MDEV-18727 improve DML operation of System Versioning
MDEV-18957 UPDATE with LIMIT clause is wrong for versioned partitioned tables

UPDATE, DELETE: replace linear search of current/historical records
with vers_setup_conds().

Additional DML cases in view.test
2019-11-22 14:29:03 +03:00
68ed3a81f2 MDEV-20854: ANALYZE for statements: not clear where the time is spent
Count the "gap" time between table accesses and display it as
r_other_time_ms in the "table" element.

* The advantage of this approach is that it doesn't add any new
  my_timer_cycles() calls.
* The disadvantage is that the definition of what is done during
  "other time" is not that clear: it includes checking the WHERE
  (for this table), constructing index lookup tuple (for the next table)
  writing to GROUP BY temporary table (as we dont account for that time
  separately [yet], etc)
2019-11-12 14:40:00 +03:00
3ad37ed0eb Merge 10.4 into 10.5 2019-11-07 08:52:30 +01:00
ec40980ddd Merge 10.3 into 10.4 2019-11-01 15:23:18 +02:00
b62101f84b Fixes for binary logging --read-only mode
- Any temporary tables created under read-only mode will never be logged
  to binary log.  Any usage of these tables to update normal tables, even
  after read-only has been disabled, will use row base logging (as the
  temporary table will not be on the slave).
- Analyze, check and repair table will not be logged in read-only mode.

Other things:
- Removed not used varaibles in
  MYSQL_BIN_LOG::flush_and_set_pending_rows_event.
- Set table_share->table_creation_was_logged for all normal tables.
- THD::binlog_query() now returns -1 if statement was not logged., This
  is used to update table_share->table_creation_was_logged.
- Don't log admin statements in opt_readonly is set.
- Table's that doesn't have table_creation_was_logged will set binlog format to row
  logging.
- Removed not needed/wrong setting of table->s->table_creation_was_logged
  in create_table_from_items()
2019-10-20 11:52:29 +03:00
57a09a72a3 cleanup st_select_lex_unit::explainable 2019-10-14 10:29:31 +02:00
a4a025f5d1 cleanup: don't pass wild_num to setup_wild()
because internally setup_wild() adjusts select_lex->with_wild directly
anyway, so there is no reason to pretend that the number of '*' may be
anything else but select_lex->with_wild

And don't update select_lex->item_list, because fields can come
from anywhere and don't necessarily have to be copied into select_lex.
2019-10-14 10:29:30 +02:00
fab84ec979 removes references to a sysvar that disappeared 6 years ago 2019-09-28 19:21:10 +02:00
244f0e6dd8 Merge branch '10.3' into 10.4 2019-09-06 11:53:10 +02:00
537f8594a6 Merge 10.2 into 10.3 2019-09-04 17:52:04 +03:00
c7c481f4d9 MDEV-20403 Assertion 0' or Assertion btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIMESTAMP..ON UPDATE
Three issues here:
* ON UPDATE DEFAULT NOW columns were updated after generated columns
  were computed - this broke indexed virtual columns
* ON UPDATE DEFAULT NOW columns were updated after BEFORE triggers,
  so triggers didn't see the correct NEW value
* in case of a multi-update generated columns were also updated
  after BEFORE triggers
2019-09-03 20:34:30 +02:00
3789692d17 don't compare unassigned columns
on UPDATE, compare_record() was comparing all columns that are marked
for writing. But generated columns that are written to the table are
always deterministic and cannot change unless normal non-generated
columns were changed. So it's enough to compare only non-generated
columns that were explicitly assigned values in the SET clause.
2019-09-03 20:34:30 +02:00
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
bff7cf9df8 Fix of fail of period.updtae with ps protocol. 2019-06-15 18:58:31 +02:00
f66d1850ac Merge branch '10.3' into 10.4 2019-06-14 22:10:50 +02:00
4a3d51c76c Merge branch '10.2' into 10.3 2019-06-14 07:36:47 +02:00
50653e021f Merge branch '10.1' into 10.2 2019-06-13 16:42:21 +02:00
5b65d61d93 Merge branch '5.5' into 10.1 2019-06-12 22:54:46 +02:00
6660c072ad MDEV-19491 update query stopped working after mariadb upgrade 10.2.23 -> 10.2.24
as well as

MDEV-19500 Update with join stopped worked if there is a call to a procedure in a trigger
MDEV-19521 Update Table Fails with Trigger and Stored Function
MDEV-19497 Replication stops because table not found
MDEV-19527 UPDATE + JOIN + TRIGGERS = table doesn't exists error

Reimplement the fix for (5d510fdbf0)

MDEV-18507 can't update temporary table when joined with table with triggers on read-only

instead of calling open_tables() twice, put multi-update
prepare code inside open_tables() loop.

Add a test for a MDL backoff-and-retry loop inside open_tables()
across multi-update prepare code.
2019-06-01 09:43:40 +02:00
1d4ac3d4d3 cleanup 2019-06-01 09:43:40 +02:00
c07325f932 Merge branch '10.3' into 10.4 2019-05-19 20:55:37 +02:00
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
c51f85f882 Merge branch '10.2' into 10.3 2019-05-12 17:20:23 +02:00
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
b132b8895e Merge 10.3 into 10.4 2019-05-05 10:23:14 +03:00
8cbb14ef5d Merge branch '10.1' into 10.2 2019-05-04 17:04:55 +02:00
4d59f45260 Merge 10.2 into 10.3 2019-04-27 20:41:31 +03:00
2ce52790ff Merge branch '5.5' into 10.1 2019-04-26 14:02:37 +02:00
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
e6bdf77e4b Merge 10.3 into 10.4
In is_eits_usable(), we disable an assertion that fails due to
MDEV-19334.
2019-04-25 16:05:20 +03:00
acf6f92aa9 Merge 10.2 into 10.3 2019-04-25 09:05:52 +03:00
bc145193c1 Merge 10.1 into 10.2 2019-04-25 09:04:09 +03:00
5d510fdbf0 MDEV-18507 can't update temporary table when joined with table with triggers on read-only
triggers are opened and tables used in triggers are prelocked in
open_tables(). But multi-update can detect what tables will actually
be updated only later, after all main tables are opened.

Meaning, if a table is used in multi-update, but is not actually updated,
its on-update treggers will be opened and tables will be prelocked,
even if it's unnecessary. This can cause more tables to be
write-locked than needed, causing read_only errors, privilege errors
and lock waits.

Fix: don't open/prelock triggers unless table->updating is true.
In multi-update after setting table->updating=true, do a second
open_tables() for newly added tables, if any.
2019-04-24 11:15:38 +02:00
5057d46375 bugfix: multi-update checked privileges on views incorrectly
it always required UPDATE privilege on views, not being able to detect
when a views was not actually updated in multi-update.

fix: instead of marking all tables as "updating" by default,
only set "updating" on tables that will actually be updated
by multi-update. And mark the view "updating" if any of the
view's tables is.
2019-04-24 11:15:38 +02:00
409dddf695 MDEV-18300: ASAN error in Field_blob::get_key_image upon UPDATE with subquery
For single table updates and multi-table updates , engine independent statistics were not being
read even if the statistics were collected.
Fixed it, so when the optimizer_use_condition_selectivity > 2 then we would read the available
statistics for update queries.
2019-04-11 13:05:01 +05:30
5fc6ad95d4 MDEV-18921 Server crashes in bitmap_bits_set or bitmap_is_set upon UPDATE IGNORE .. FOR PORTION with binary logging
The fix is same as for MDEV-18859: initialize table->rpl_write_set in
FOR PORTION OF case.
2019-04-02 11:03:32 +02:00
04055060b6 MDEV-18852 MDEV-18853 fix period.delete, period.update tests crashes with `--ps-protocol
The main problem was lack of proper QueryArena handling in
`period_setup_conds`. Since mysql_prepare_update/mysql_prepare_delete
are called during `PREPARE` statement, period conditions, should be
allocated on statement query arena.

Another problem is incorrect statement state handling in
period_setup_conds, which led to unexpected mysql_update termination.

* mysql_update: move period_setup_conds() to mysql_prepare_update to
  store conditions in statement's mem_root

* mtr: add period suite to default list, since --ps-protocol is now
  fixed

Fixes bugs:
MDEV-18853 Assertion `0' failed in Protocol::end_statement upon DELETE .. FOR PORTION via prepared statement
MDEV-18852 Server crashes in reinit_stmt_before_use upon UPDATE .. FOR PORTION via prepared statement
2019-04-02 11:03:32 +02:00
5c3ff5cb93 Merge 10.3 into 10.4 2019-04-02 11:04:54 +03:00