| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem, introduced in patch for MDEV-26301:
When check_join_cache_usage() decides not to use join buffer, it must
adjust the access method accordingly. For BNL-H joins this means switching
from pseudo-"ref access"(with index=MAX_KEY) to some other access method.
Failing to do this will cause assertions down the line when code that is
not aware of BNL-H will try to initialize index use for ref access with
index=MAX_KEY.
The fix is to follow the regular code path to disable the join buffer for
the join_tab ("goto no_join_cache") instead of just returning from
check_join_cache_usage().
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
with views and HAVING
Do not try to decide merge/materialize for derived if it was already decided
(even if it is a view).
|
| |
| |
| |
| |
| |
| | |
RocksDB (in a submodule) has to include <cstdint> to use uint64_t
but it doesn't. Until the submodule is upgraded, let's replace
problematic types with something that's available
|
| |
| |
| |
| |
| |
| |
| |
| | |
DUPLICATE KEY in some cases
select_insert::store_values() must reset
has_value_set bitmap before every row, just like mysql_insert() does.
because ON DUPLICATE KEY UPDATE and triggers modify it
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
EXPLAIN EXTENDED DELETE
Temporary fix to avoid the server crash.
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Add Optimizer Trace printouts.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This patch optimizes the number of refills for the lateral derived table
to which a materialized derived table subject to split optimization is
is converted. This optimized number of refills is now considered as the
expected number of refills of the materialized derived table when searching
for the best possible splitting of the table.
|
|\ \
| |/ |
|
| |
| |
| |
| |
| | |
(part 1 is in the previous commit)
to [ pass ] galera.MDEV-18832, galera.MDEV-27862
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |\ |
|
| | | |
|
|\ \ \
| |/ / |
|
| |\ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Update wsrep-lib which contains fix for the assertion
- Fix error handling for appending fragment to streaming log,
make sure tables are closed after rollback.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
changed tast case 2 to be deterministic
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1. log_event.cc stuff should go into log_event_server.cc
2. the test's wait condition is textually different in 10.5, fixed.
3. pre-exec 'optimistic' global var value is correct for 10.5 indeed.
|
|\ \ \ \
| |/ / / |
|
| |\ \ \
| | |/ /
| |/| /
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When using binlog_row_image=FULL with sequence table inserts, a
replica can deadlock because it treats full inserts in a sequence as DDL
statements by getting an exclusive lock on the sequence table. It
has been observed that with parallel replication, this exclusive
lock on the sequence table can lead to a deadlock where one
transaction has the exclusive lock and is waiting on a prior
transaction to commit, whereas this prior transaction is waiting on
the MDL lock.
This fix for this is on the master side, to raise FL_DDL
flag on the GTID of a full binlog_row_image write of a sequence table.
This forces the slave to execute the statement serially so a deadlock
cannot happen.
A test verifies the deadlock also to prove it happen on the OLD (pre-fixes)
slave.
OLD (buggy master) -replication-> NEW (fixed slave) is provided.
As the pre-fixes master's full row-image may represent both
SELECT NEXT VALUE and INSERT, the parallel slave pessimistically
waits for the prior transaction to have committed before to take on the
critical part of the second (like INSERT in the test) event execution.
The waiting exploits a parallel slave's retry mechanism which is
controlled by `@@global.slave_transaction_retries`.
Note that in order to avoid any persistent 'Deadlock found' 2013 error
in OLD -> NEW, `slave_transaction_retries` may need to be set to a
higher than the default value.
START-SLAVE is an effective work-around if this still happens.
|
| | | |
|
| | |\ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Adding virtual methods to class Schema:
make_item_func_replace()
make_item_func_substr()
make_item_func_trim()
This is a non-functional preparatory change for MDEV-27744.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
The fix was introduced, along with re-ordering to do other macros that check test environment capabilities before master/slave is set up.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Variant #2.
When Histogram::point_selectivity() sees that the point value of interest
falls into one bucket, it tries to guess whether the bucket has many
different (unpopular) values or a few popular values. (The number of
rows is fixed, as it's a Height-balanced histogram).
The basis for this guess is the "width" of the value range the bucket
covers. Buckets covering wider value ranges are assumed to contain
values with proportionally lower frequencies.
This is just a [brave] guesswork. For a very narrow bucket, it may
produce an estimate that's larger than total #rows in the bucket
or even in the whole table.
Remove the guesswork and replace it with basic logic: return
either the per-table average selectivity of col=const, or selectivity
of one bucket, whichever is lower.
|
| | | |
| | | |
| | | |
| | | | |
exclude generated columns from the "has default value" check
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Type_handler_string_result::make_sort_key with DISTINCT and group function
Fix-up for commit 476b24d084e7e717310155bb986eb086d3c1e1a6
Author: Monty
Date: Thu Feb 16 14:19:33 2023 +0200
MDEV-20057 Distinct SUM on CROSS JOIN and grouped returns wrong result
which misses initializing of sorder->suffix_length.
In this commit the initialization is implemented by passing
MY_ZEROFILL flag to the allocation of SORT_FIELD elements
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
conversion
FreeBSD 13.2
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Keep Item_in_optimizer cache always (but only once) in statement memory.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix leack in TABLE_SHARE::init_from_sql_statement_string
by removing uneeded switching arenas.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix leack in Item_subselect::mark_as_dependent (allocation
of temporary list in statement memory inctroduced in
f4d552104364fe195237f39862d91f657c7a34cb )
|
|\ \ \ \ |
|
| | | | | |
|
|\ \ \ \ \
| | |/ / /
| |/| | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
followup for d1a46c68cd4
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
remove ancient hard-coded treatment of --core-file. This enables
normal my_getopt behavior for the already existing sysvar
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The error was seen by a number of mtr tests being caused
by overdue initialization of rpl_parallel::LOCK_parallel_entry.
Specifically, SHOW-SLAVE-STATUS might find in
rpl_parallel::workers_idle() a gtid domain hash entry
already inserted whose mutex had not done
mysql_mutex_init().
Fixed with swapping the mutex init and the its entry's stack insertion.
Tested with a generous number of `mtr --repeat` of a few of the reported
to fail tests, incl rpl.parallel_backup.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Timers require my_timer_init() call.
It was made only in mysqld_main(). Call it also from init_embedded_server().
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
replication
When replicating MDL events for a table that uses system versioning
without primary keys, ensure that for data sets with duplicate
records, the updates to these records with duplicates are enacted on
the correct row. That is, there was a bug (reported in MDEV-30430)
such that the function to find the row to update would stop after
finding the first matching record. However, in the absence of
primary keys, the version of the record is needed to compare the row
to ensure we are updating the correct one.
The fix, therefore, updates the record comparison functionality to
use system version columns when there are no primary keys on the
table.
Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>
|