fts_sync(): If the dict_table_t::to_be_dropped flag is set,
do not "goto begin_sync".
Also, clean up the way how dict_index_t::index_fts_syncing
is cleared.
It looks like this regression was introduced by merging
Oracle Bug #24938374 MYSQL CRASHED AFTER LONG WAIT ON DICT OPERATION LOCK
WHILE SYNCING FTS INDEX
068f8261d4
from MySQL 5.6.38 into MariaDB 10.0.33, 10.1.29, 10.2.10.
The same hang is present in MySQL 5.7.20.
Also handle Postgresql sending type VARCHAR for TEXT column and
setting length to b x7FFFFFF when the length is unknown.
modified: storage/connect/Client.java
modified: storage/connect/JavaWrappers.jar
modified: storage/connect/JdbcInterface.java
modified: storage/connect/PostgresqlInterface.java
modified: storage/connect/global.h
modified: storage/connect/ha_connect.cc
modified: storage/connect/jdbconn.cpp
modified: storage/connect/jdbconn.h
modified: storage/connect/mysql-test/connect/r/jdbc_postgresql.result
modified: storage/connect/mysql-test/connect/t/jdbc_postgresql.test
modified: storage/connect/mysql-test/connect/t/jdbconn.inc
modified: storage/connect/plgdbsem.h
modified: storage/connect/tabjdbc.cpp
modified: storage/connect/tabjdbc.h
The error log redirection for wsrep_recover run does not work in old version.
For the wsrep_recovery run, error logging is supposed to go into:
mysql-test/suite/galera/include/galera_wsrep_recover.inc
In old version, this works only partially, 4 first lines of error messages after mysql startup
do go into the galera_wsrep_recover.log, but after that the default error log file is enforced
and remaining error logging goes into the default error log file.
In this patch this problem is fixed by passing --log-error option in mysql startup
This fix was tested with galera_gcache_recover test, which is currently in disabled state.
Note that the test does not pass even after this fix, as there are further more issues
in later test phases.
fil_space_t::atomic_write_supported: Always set this flag for
TEMPORARY TABLESPACE and during IMPORT TABLESPACE. The page
writes during these operations are by definition not crash-safe
because they are not written to the redo log.
fil_space_t::use_doublewrite(): Determine if doublewrite should
be used.
buf_dblwr_update(): Add assertions, and let the caller check whether
doublewrite buffering is desired.
buf_flush_write_block_low(): Disable the doublewrite buffer for
the temporary tablespace and for IMPORT TABLESPACE.
fil_space_set_imported(), fil_node_open_file(), fil_space_create():
Initialize or revise the space->atomic_write_supported flag.
buf_page_io_complete(), buf_flush_write_complete(): Add the parameter
dblwr, to indicate whether doublewrite was used for writes.
buf_dblwr_sync_datafiles(): Remove an unnecessary flush of
persistent tablespaces when flushing temporary tablespaces.
(Move the call to buf_dblwr_flush_buffered_writes().)
The crash occurs when inserting into, updating or deleting from Spider system
tables. These operations do not go through the normal insert, update or
delete logic, so binary logging of the row is not properly set up and leads
to the crash.
The fix for this problem uses the same strategy as is used for the servers
system table that contains entries for the servers created with CREATE SERVER.
Binary logging is now temporarily disabled on insert, update and delete
operations on Spider system tables.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Test MW-286 occasionally failed with error the following message:
```
safe_mutex: Found wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill'
Mutex currently locked (in reverse order):
LOCK_thd_kill mariadb-server/sql/sql_class.h line 3535
LOCK_wsrep_thd mariadb-server/sql/wsrep_thd.cc line 88
```
The fix consists in calling thd->reset_killed() in wsrep_mysql_parse() after
LOCK_wsrep_thd is unlocked. Which avoids the taking locks LOCK_wsrep_thd and
LOCK_thd_kill in reverse order.
This test failed to work properly because the fixes it came
with were not merged from upstream.
The test would fail with a spurious ER_LOCK_DEADLOCK error
for a conflict that happened earlier in the test execution,
while wsrep is disabled.
The original fix was to set THD::wsrep_conflict_state only
if wsrep is enabled (see wsrep_thd_set_conflict_state() in
sql/wsrep_mysqld.cc)
InnoDB in Debian uses utf8mb4 as default character set since
version 10.0.20-2. This leads to major pain due to keys longer
than 767 bytes.
MariaDB 10.2 (and MySQL 5.7) introduced the setting
innodb_default_row_format that is DYNAMIC by default. These
versions also changed the default values of the parameters
innodb_large_prefix=ON and innodb_file_format=Barracuda.
This would allow longer column index prefixes to be created.
The original purpose of these parameters was to allow InnoDB
to be downgraded to MySQL 5.1, which is long out of support.
Every InnoDB version since MySQL 5.5 does support operation
with the relaxed limits.
We backport the parameter innodb_default_row_format to
MariaDB 10.1, but we will keep its default value at COMPACT.
This allows MariaDB 10.1 to be configured so that CREATE TABLE
is less likely to encounter a problem with the limitation:
loose_innodb_large_prefix=ON
loose_innodb_default_row_format=DYNAMIC
(Note that the setting innodb_large_prefix was deprecated in
MariaDB 10.2 and removed in MariaDB 10.3.)
The only observable difference in the behaviour with the default
settings should be that ROW_FORMAT=DYNAMIC tables can be created
both in the system tablespace and in .ibd files, no matter what
innodb_file_format has been assigned to. Unlike MariaDB 10.2,
we are not changing the default value of innodb_file_format,
so ROW_FORMAT=COMPRESSED tables cannot be created without
changing the parameter.
The loop in ull2dec() does not iterate if "from" is zero,
so to->intg got erroneously set to 0 instead of 1.
Because if this, my_decimal2seconds() wrote the fractional
part into a wrong buf[x].
Catching the special case with zero "from" and properly initialize "to"
using decimal_make_zero().
Analysis:- The problem is the change in the implementation of wait_for_listen
in wsrep_sst_xtrabackup-v2.sh. The new script uses lsof which will always
exit with an error code if it can't find all the items, and because the
script has the -e option set in the hashbang line (#!/bin/bash -ue), the
script will abort right after running lsof if lsof can't find even a single
item among all the items listed in its arguments. This will happen even if
socat is running and listening, because it can't find nc. The loop in
wait_for_listen will therefore always quit after one iteration without
writing the "ready" line to signal the parent.
Solution:- We will or the lsof with true.
Patch Credit :Daniel Black and David Wang
a) We do not need this on Windows, and it is not clear what it does,inside
service.
b) It hinders debugging.
mysql-test-run.pl --debugger=vsjitdebugger more often than , would stop here
throwing "invalid handle" exception.
the non-recursive CTE via prepared statement
The problem appears as the column names of the CTE were allocated on the
wrong MEMROOT and after the preparation of the statement they disappear.
To fix it in the procedure With_element::rename_columns_of_derived_unit
the CTE column names are now allocated in the permanent MEMROOT for the
prepared statements and stored procedures.
