| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
to 'DEFAULT' in 10.7
- When GLOBAL tmp_table_plugin variable is set to default,
thd->lex->plugins dynamic array doesn't insert the value during
on_check() method but later so it is safe to skip it.
Reviewed by: vicentiu@mariadb.org
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RocksDB is substituted silently
- There should be no substitution if engine exists, only when doesn't
exist
- Handling of an error when sys_var `default_tmp_storage_engine` is
assigned to unsupported engine.
- rocksdb doesn't support embedded server ebfc4e6ad02 so is excluded
Closes PR #774
Reviewed by: serg@mariadb.com
vicentiu@mariadb.org
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
net_send_ok
add a test case (commented, as user var tracker is disabled)
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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).
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The replacement of buf_pool.page_hash with a different type of
hash table in commit 5155a300fab85e97217c75e3ba3c3ce78082dd8a (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.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
followup for bfedf1eb4b6
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | |
| | | |
SIGSEGV in ha_maria::extra
|
| | | |
| | |
| | |
| | |
| | |
| | | |
for views.
privilege checks for tables flushed via views
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |\ \
| | |/ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
square brackets are not included
make test results stable
followup for 98c7916f0f2
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 7a27db778e3e5a04271568a94c75157bb6fb48f1 (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.
|
| | | | |\ |
|
| | | | | |\ |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
One more result was affected by merging
768c51880a5aa6d25d4c0fe7de7a88561ff46422.
|
| | | |\ \ \ \
| | | |/ / / |
|
| | | | |\ \ \
| | | | |/ / |
|
| | | | | |\ \
| | | | | |/ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is a backport of 161e4bfafd261aa5204827086637d4d7dcceb949.
trans_rollback_to_savepoint(): Only release metadata locks (MDL)
if the storage engines agree, after the changes were already rolled back.
Ever since commit 3792693f311a90cf195ec6d2f9b3762255a249c7
and mysql/mysql-server@55ceedbc3feb911505dcba6cee8080d55ce86dda
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 1bd681c8b3c5213ce1f7976940a7dc38b48a0d39 (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 3792693f311a90cf195ec6d2f9b3762255a249c7
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
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixup for commit 768c51880a5aa6d25d4c0fe7de7a88561ff46422
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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().
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The error loading the client module is different
|
| | | | |\ \ \
| | | | |/ / |
|
| | | | | | | |
|
| | | | | |\ \
| | | | | |/ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 768c51880a5aa6d25d4c0fe7de7a88561ff46422
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Parital backport of 48938c57c7f75b2a7627212b01cd65cfd6830261
so platform dependent AIX tests can be done.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Parital backport of 48938c57c7f75b2a7627212b01cd65cfd6830261
so platform dependent AIX tests can be done.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
list uses SP
Post-merge fix in 10.4: add a testcase for pushdown into IN subquery
|
| | | | |\ \ \
| | | | |/ / |
|
| | | | | | | |
|
| | | | | |\ \
| | | | | |/ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add KEYWORDS table and SQL_FUNCTIONS table to INFORMATION_SCHEMA.
This commits needs some minor changes when propagated upwards
(e.g. func_array in item_create.cc has a termination element that
doesn't exist in later versions of MariaDB)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
os_file_set_size(): Trim the current size down to the file system
block size, to obey the constraints for unbuffered I/O.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Geometry::create_from_json.
Handle invalid GEOJSON-s in Geometry::create_from_json().
|
| | | | | | | |
|
| | | | | | | |
|
