MDEV-28506 Possible item replacement during fix_fields() is not taken into account when pushing conditions from HAVING to WHERE
1. During the 5th stage of pushdown_from_having_into_where() there is
a sequence of cleanup/fix_fields calls for items involved. fix_fields()
may sometimes replace the initial item, which is done, for example, for
Item_func_not. This commits adds the correct handling for such cases.
2. Sometimes fix_fields() calls are made with the 2nd parameter
(Item **ref) set to NULL. This may lead to access violation when the item
is of class Item_func_not or Item_func_sp. This commits add a proper check
before dereferencing **ref.
MDEV-31332: Galera rsync sst to ignore .snapshot/ files
.snapshot exists as a directory on NetApp storage and
should not be copied during the sst process.
Thanks Daniel Czadek for the bug report.
Signed-off-by: Julius Goryavsky <email address hidden>
f5c3e73...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-31651 : Assertion wsrep_thd_is_applying(thd) && !wsrep_thd_is_local_toi(thd) in wsrep_ignored_error_code
Problem was that with BINLOG-statement you can execute
binlog events on master also (not only in applier).
Fix removes too strict part wsrep_thd_is_applying from
assertion. Note that actual event in test is intentionally
corrupted to test should this error being ignored.
Signed-off-by: Julius Goryavsky <email address hidden>
8a5a07f...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
Problem:
=========
During commit, server calls prepare_commit_versioned to
determine the transaction modified system-versioned data.
Due to binlog_do_db option, we disable the binlog for the
statement. But prepare_commit_versioned() is being
called only when binlog is enabled for the statement.
Fix:
===
prepare_commit_versioned() should happen irrespective
of binlog state. So if the server has any read-write operation
then we should call prepare_commit_versioned().
MDEV-18200 MariaBackup full backup failed with InnoDB: Failing assertion: success
There are many filesystem related errors that can occur with
MariaBackup. These already outputed to stderr with a good description of
the error. Many of these are permission or resource (file descriptor)
limits where the assertion and resulting core crash doesn't offer
developers anything more than the log message. To the user, assertions
and core crashes come across as poor error handling.
As such we return an error and handle this all the way up the stack.
MDEV-25163 Rowid filter does not process storage engine error correctly.
The fix is to return 3-state value from Range_rowid_filter::build()
call:
1. The filter was built successfully;
2. The filter was not built, but the error was not fatal, i.e. there is
no need to rollback transaction. For example, if the size of container to
storevrow ids is not enough;
3. The filter was not built because of fatal error, for example,
deadlock or lock wait timeout from storage engine. In this case we
should stop query plan execution and roll back transaction.
is_file_on_ssd() is more expensive than it should be.
It caches the results by volume name, but still calls GetVolumePathName()
every time, which, as procmon shows, opens multiple directories in
filesystem hierarchy (db directory, datadir, and all ancestors)
The fix is to cache SSD status by volume serial ID, which is cheap to
retrieve with GetFileInformationByHandleEx()
