Commit graph

193321 commits

Author SHA1 Message Date
Sergei Golubchik
94c508dd4f MDEV-22709 Assertion `store.length() <= (256L*256L*256L-1)' failed in net_send_ok
add a test case (commented, as user var tracker is disabled)
2021-07-06 00:07:30 +02:00
Sergei Golubchik
1f2ccc6db8 update C/C to 3.2.3 2021-07-05 12:44:09 +02:00
Sergei Golubchik
6fa72fb1f2 mtr: report full command line of mysqld that failed to start 2021-07-04 12:11:09 +02:00
Marko Mäkelä
789a2a363a fixup 0a67b15a9d
trx_t::free(): Declare xid as fully initialized in order to
avoid tripping the subsequent MEM_CHECK_DEFINED
(in WITH_MSAN and WITH_VALGRIND builds).
2021-07-03 20:35:29 +03:00
Marko Mäkelä
b797f217a3 Merge 10.5 into 10.6 2021-07-03 14:54:46 +03:00
Marko Mäkelä
f0f47cbca1 MDEV-26017 fixup
buf_flush_relocate_on_flush_list(): Use dpage->physical_size()
because bpage->zip.ssize may already have been zeroed in
page_zip_set_size() invoked by buf_pool_t::realloc().

This would cause occasional failures of the test
innodb.innodb_buffer_pool_resize, which creates a
ROW_FORMAT=COMPRESSED table.
2021-07-03 14:52:04 +03:00
Marko Mäkelä
bd5a6403ca MDEV-26033: Race condition between buf_pool.page_hash and resize()
The replacement of buf_pool.page_hash with a different type of
hash table in commit 5155a300fa (MDEV-22871)
introduced a race condition with buffer pool resizing.

We have an execution trace where buf_pool.page_hash.array is changed
to point to something else while page_hash_latch::read_lock() is
executing. The same should also affect page_hash_latch::write_lock().

We fix the race condition by never resizing (and reallocating) the
buf_pool.page_hash. We assume that resizing the buffer pool is
a rare operation. Yes, there might be a performance regression if a
server is first started up with a tiny buffer pool, which is later
enlarged. In that case, the tiny buf_pool.page_hash.array could cause
increased use of the hash bucket lists. That problem can be worked
around by initially starting up the server with a larger buffer pool
and then shrinking that, until changing to a larger size again.

buf_pool_t::resize_hash(): Remove.

buf_pool_t::page_hash_table::lock(): Do not attempt to deal with
hash table resizing. If we really wanted that in a safe manner,
we would probably have to introduce a global rw-lock around the
operation, or at the very least, poll buf_pool.resizing, both of
which would be detrimental to performance.
2021-07-03 13:58:38 +03:00
Sergei Golubchik
9ec3cd9af0 gamma -> stable 2021-07-02 23:52:55 +02:00
Sergei Golubchik
028d611832 update test result
followup for  bfedf1eb4b
2021-07-02 20:36:37 +02:00
Sergei Golubchik
59bc063d26 main.lock_kill fails in embedded
when killing a query in a parallel connection, disable warnings.
Because --error doesn't apply to automatically sent SHOW WARNINGS,
so if KILL arrives at the right moment the test will fail with

mysqltest: At line 41: Error running query "SHOW WARNINGS": Server has gone away
2021-07-02 16:44:00 +02:00
Sergei Golubchik
4145ebf99a MDEV-25906: SIGSEGV in flush_tables_with_read_lock on FTWRL or FTFE | SIGSEGV in ha_maria::extra 2021-07-02 16:44:00 +02:00
Sergei Golubchik
164a64baa3 MDEV-15888 Implement FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK for views.
privilege checks for tables flushed via views
2021-07-02 16:44:00 +02:00
Sergei Golubchik
b5f50e2de8 errors after altering a table has finished aren't fatal
We cannot revert the ALTER, so anything happening after
the point of no return should not be treated as an error. A
very unfortunate condition that a user needs to be warned about - yes,
but we cannot say "ALTER TABLE has failed" if the table was successfully
altered.
2021-07-02 16:44:00 +02:00
Marko Mäkelä
0ad8a825a8 Merge 10.5 into 10.6 2021-07-02 17:00:05 +03:00
Sergei Golubchik
779262842e MDEV-23004 When using GROUP BY with JSON_ARRAYAGG with joint table, the square brackets are not included
make test results stable

followup for 98c7916f0f
2021-07-02 16:23:48 +03:00
Marko Mäkelä
8c029d426a Merge 10.4 into 10.5 2021-07-02 16:19:25 +03:00
Marko Mäkelä
a635588b56 MDEV-25236 Online log apply fails for ROW_FORMAT=REDUNDANT tables
In other ROW_FORMAT than REDUNDANT, the InnoDB record header
size calculation depends on dict_index_t::n_core_null_bytes.

In ROW_FORMAT=REDUNDANT, the record header always is 6 bytes
plus n_fields or 2*n_fields bytes, depending on the maximum
record size. But, during online ALTER TABLE, the log records
in the temporary file always use a format similar to
ROW_FORMAT=DYNAMIC, even omitting the 5-byte fixed-length part
of the header.

While creating a temporary file record for a ROW_FORMAT=REDUNDANT
table, InnoDB must refer to dict_index_t::n_nullable.
The field dict_index_t::n_core_null_bytes is only valid for
other than ROW_FORMAT=REDUNDANT tables.

The bug does not affect MariaDB 10.3, because only
commit 7a27db778e (MDEV-15563)
allowed an ALGORITHM=INSTANT change of a NOT NULL column to
NULL in a ROW_FORMAT=REDUNDANT table.

The fix was developed by Thirunarayanan Balathandayuthapani
and tested by Matthias Leich. The test case was simplified by me.
2021-07-02 16:11:01 +03:00
Marko Mäkelä
372ea88264 Merge 10.3 into 10.4 2021-07-02 14:55:52 +03:00
Marko Mäkelä
f9194d02da Merge 10.2 into 10.3 2021-07-02 14:41:41 +03:00
Marko Mäkelä
a6adefad4b Fixup 586870f9ef
One more result was affected by merging
768c51880a.
2021-07-02 14:41:32 +03:00
Eugene Kosov
ffe744e77d submodules.cmake: add missing --depth=1 2021-07-02 13:25:20 +03:00
Marko Mäkelä
15dcb8bd3e Merge 10.4 into 10.5 2021-07-02 13:02:26 +03:00
Marko Mäkelä
c294443b41 Merge 10.3 into 10.4 2021-07-02 11:48:51 +03:00
Marko Mäkelä
05f7fd571f Merge 10.2 into 10.3 2021-07-02 11:44:51 +03:00
Marko Mäkelä
2bf6f2c054 MDEV-26077 Assertion err != DB_DUPLICATE_KEY or unexpected ER_TABLE_EXISTS_ERROR
This is a backport of 161e4bfafd.

trans_rollback_to_savepoint(): Only release metadata locks (MDL)
if the storage engines agree, after the changes were already rolled back.

Ever since commit 3792693f31
and mysql/mysql-server@55ceedbc3f
we used to cheat here and always release MDL if the binlog is disabled.

MDL are supposed to prevent race conditions between DML and DDL also
when no replication is in use. MDL are supposed to be a superset of
InnoDB table locks: InnoDB table lock may only exist if the thread
also holds MDL on the table name.

In the included test case, ROLLBACK TO SAVEPOINT would wrongly release
the MDL on both tables and let ALTER TABLE proceed, even though the DML
transaction is actually holding locks on the table.

Until commit 1bd681c8b3 (MDEV-25506)
in MariaDB 10.6, InnoDB would often work around the locking violation
in a blatantly non-ACID way: If locks exist on a table that is being
dropped (in this case, actually a partition of a table that is being
rebuilt by ALTER TABLE), InnoDB could move the table (or partition)
into a queue, to be dropped after the locks and references had been
released. If the lock is not released and the original copy of the
table not dropped quickly enough, a name conflict could occur on
a subsequent ALTER TABLE.

The scenario of commit 3792693f31
is unaffected by this fix, because mysqldump
would use non-locking reads, and the transaction would not be holding
any InnoDB locks during the execution of ROLLBACK TO SAVEPOINT.
MVCC reads inside InnoDB are only covered by MDL and page latches,
not by any table or record locks.

FIXME: It would be nice if storage engines were specifically asked
which MDL can be released, instead of only offering a choice
between all or nothing. InnoDB should be able to release any
locks for tables that are no longer in trx_t::mod_tables, except
if another transaction had converted some implicit record locks
to explicit ones, before the ROLLBACK TO SAVEPOINT had been completed.

Reviewed by: Sergei Golubchik
2021-07-02 11:15:35 +03:00
Marko Mäkelä
5a2b625843 MDEV-25129 fixup: Adjust test result
Fixup for commit 768c51880a
2021-07-02 11:08:48 +03:00
Thirunarayanan Balathandayuthapani
e34877ab63 MDEV-25971 Instant ADD COLUMN fails to issue truncation warnings
A table rebuild that would truncate the default value of a
DATE column is expected to issue data truncation warnings.
But, these warnings are not being issued if the ADD COLUMN
is being executed with ALGORITHM=INSTANT. InnoDB sets the
warning of the field while assigning the default value
of the field during check_if_supported_inplace_alter().
2021-07-02 13:12:08 +05:30
Daniel Black
fa8eb4de55 mtr: plugin.multiauth aix fix
The error loading the client module is different
2021-07-02 17:18:51 +10:00
Daniel Black
95e9f3c186 Merge branch 10.3 into 10.4 2021-07-02 17:17:33 +10:00
Daniel Black
6a3a046013 mtr: aix - no pool of threads 2021-07-02 17:17:19 +10:00
Daniel Black
2301093f8f MDEV-25894: support AIX as a platform in mtr
Parital backport of 48938c57c7
so platform dependent AIX tests can be done.
2021-07-02 17:17:19 +10:00
Daniel Black
7ce5984d6d mtr: fix tests funcs_1.is_tables_is & sql_sequence.rebuild 2021-07-02 16:42:21 +10:00
Daniel Black
a88ddb168f Merge branch '10.2' into 10.3 2021-07-02 16:35:49 +10:00
Daniel Black
c22f7f2323 MDEV-25129 postfix for windows
C:\projects\server\sql\sql_show.cc(7913): error C2220: warning treated as error - no 'object' file generated [C:\projects\server\win_build\sql\sql.vcxproj]
C:\projects\server\sql\sql_show.cc(7913): warning C4267: 'initializing': conversion from 'size_t' to 'uint', possible loss of data [C:\projects\server\win_build\sql\sql.vcxproj]

caused by 768c51880a
2021-07-02 15:58:13 +10:00
Daniel Black
0a9487b62b mtr: aix - no pool of threads 2021-07-02 14:46:10 +10:00
Daniel Black
3f2c4758b0 MDEV-25894: support AIX as a platform in mtr
Parital backport of 48938c57c7
so platform dependent AIX tests can be done.
2021-07-02 14:46:05 +10:00
Marko Mäkelä
315380a4d1 MDEV-26052 Assertion prebuilt->trx_id < table->def_trx_id failed
ha_innobase::truncate(): If the operation fails, preserve
also dict_table_t::def_trx_id.

This fixes a regression that had been introduced in
commit 1bd681c8b3 (MDEV-25506).
2021-07-01 19:06:53 +03:00
Marko Mäkelä
ed6b230744 MDEV-25919 preparation: Remove trx_t::internal
With commit 1bd681c8b3 (MDEV-25506)
it no longer is necessary to run DDL and DML operations in
separate transactions. Let us remove the flag trx_t::internal.
Dictionary transactions will be distinguished by trx_t::dict_operation.
2021-07-01 17:51:55 +03:00
Marko Mäkelä
0a67b15a9d Cleanup: Remove pointer indirection for trx_t::xid
The trx_t::xid is always allocated, so we might as well allocate it
directly in the trx_t object to improve the locality of reference.
2021-07-01 16:38:24 +03:00
Marko Mäkelä
83234719f1 MDEV-24671 fixup: Fix an off-by-one error
In commit e71e613353 we
accidentally made innodb_lock_wait_timeout=100000000
a "literal" value, not the smallest special value that
would mean "infinite" timeout.
2021-07-01 16:37:01 +03:00
Marko Mäkelä
161e4bfafd MDEV-25902 Unexpected ER_LOCK_WAIT_TIMEOUT and result
trans_rollback_to_savepoint(): Only release metadata locks (MDL)
if the storage engines agree, after the changes were already rolled back.

Ever since commit 3792693f31
and mysql/mysql-server@55ceedbc3f
we used to cheat here and always release MDL if the binlog is disabled.

MDL are supposed to prevent race conditions between DML and DDL also
when no replication is in use. MDL are supposed to be a superset of
InnoDB table locks: InnoDB table lock may only exist if the thread
also holds MDL on the table name.

In the included test case, ROLLBACK TO SAVEPOINT would wrongly release
the MDL on both tables and let ALTER TABLE proceed, even though the DML
transaction is actually holding locks on the table.

Until commit 1bd681c8b3 (MDEV-25506)
InnoDB worked around the locking violation in a blatantly non-ACID way:
If locks exist on a table that is being dropped (in this case, actually
a partition of a table that is being rebuilt by ALTER TABLE), InnoDB
would move the table (or partition) into a queue, to be dropped after
the locks and references had been released.

The scenario of commit 3792693f31
is unaffected by this fix, because mariadb-dump (a.k.a. mysqldump)
would use non-locking reads, and the transaction would not be holding
any InnoDB locks during the execution of ROLLBACK TO SAVEPOINT.
MVCC reads inside InnoDB are only covered by MDL and page latches,
not by any table or record locks.

FIXME: It would be nice if storage engines were specifically asked
which MDL can be released, instead of only offering a choice
between all or nothing. InnoDB should be able to release any
locks for tables that are no longer in trx_t::mod_tables, except
if another transaction had converted some implicit record locks
to explicit ones, before the ROLLBACK TO SAVEPOINT had been completed.

Reviewed by: Sergei Golubchik
2021-07-01 10:35:32 +03:00
Marko Mäkelä
8c5c3a4594 MDEV-26067 innodb_lock_wait_timeout values above 100,000,000 are useless
The practical maximum value of the parameter innodb_lock_wait_timeout
is 100,000,000. Any value larger than that specifies an infinite timeout.

Therefore, we should make 100,000,000 the maximum value of the parameter.
2021-07-01 10:31:08 +03:00
Marko Mäkelä
ce1c957ab1 Speed up the test innodb.lock_insert_into_empty
Let us use innodb_lock_wait_timeout=0 for an immediate timeout.
Also, do not override the timeout in the default connection,
so that further tests will use the default setting.
2021-07-01 10:04:47 +03:00
Sergei Petrunia
c7443a0911 MDEV-25969: Condition pushdown into derived table doesn't work if select list uses SP
Post-merge fix in 10.4: add a testcase for pushdown into IN subquery
2021-07-01 01:08:28 +03:00
Sergei Golubchik
add782a13e fix JSON_ARRAYAGG not to over-quote json in joins
This replaces 8711adb786

if a temptable field is created for some json expression (is_json_type()
returns true), make this temptable field a proper json field.

A field is a json field (see Item_field::is_json_type()) if it
has a CHECK constraint of JSON_VALID(field).

Note that it will never be actually checked for temptable fields,
so it won't cause a run-time slowdown.
2021-06-30 22:09:19 +02:00
Sergei Golubchik
b62672af72 MDEV-26054 Server crashes in Item_func_json_arrayagg::get_str_from_field
Revert "fix JSON_ARRAYAGG not to over-quote json in joins"
This removes 8711adb786 but keeps the test case.
A different fix is coming up.

Because args can be Item_field's that are later
replaced by Item_direct_view_ref to the actual field.
While Item_field preserved in orig_args will stay unfixed
with item->field==NULL and no metadata
2021-06-30 22:08:53 +02:00
Sergei Petrunia
eebe2090c8 Merge 10.3 -> 10.4 2021-06-30 18:41:46 +03:00
Sergei Petrunia
4a6e2d3437 Post-merge fix: update derived_cond_pushdown.result 2021-06-30 16:43:43 +03:00
Sergei Petrunia
586870f9ef Merge 10.2->10.3 2021-06-30 15:06:54 +03:00
Sergei Petrunia
eb20c91b55 MDEV-25969: Condition pushdown into derived table doesn't work if select list uses SP
Consider a query of the form:

  select ... from (select item2 as COL1) as T where COL1=123

Condition pushdown into derived table will try to push "COL1=123" condition
down into table T.
The process of pushdown involves "substituting" the item, that is,
replacing Item_field("T.COL1") with its "producing item" item2.
In order to use item2, one needs to clone it (call Item::build_clone).

If the item is not cloneable (e.g. Item_func_sp is not), the pushdown
process will fail and nothing at all will be pushed.

Fixed by introducing transform_condition_or_part() which will try to apply
the transformation for as many parts of condition as possible. The parts of
condition that couldn't be transformed are dropped.
2021-06-30 13:52:23 +03:00