Followup from 5.5 patch. Removing memory barriers on intel is wrong as
this doesn't prevent the compiler and/or processor from reorganizing reads
before the mutex release. Forcing a memory barrier before reading the waiters will
guarantee that no speculative reading takes place.
- fixes in innodb to skip wsrep processing (like kill victim) when running in native mysql mode
- similar fixes in mysql server side
- forcing tc_log_dummy in native mysql mode when no binlog used. wsrep hton messes up handler counter
and used to lead in using tc_log_mmap instead. Bad news is that tc_log_mmap does not seem to work at all
When checking is any of the renamed columns part of the
columns for new indexes we accessed NULL pointer if checked
column used on index was added on same statement. Additionally,
we tried to check too many indexes, added_index_count
is enough here.
modified: storage/connect/JdbcInterface.java
- Change Version number and date
modified: storage/connect/ha_connect.cc
- Implement the test on connect_type_conv YES/NO
modified: storage/connect/jdbconn.cpp
modified: storage/connect/odbconn.cpp
- Fix MDEV-10520. Local schema was confused with remote schema
modified: storage/connect/tabjdbc.cpp
modified: storage/connect/tabodbc.cpp
- Fix crash when using mapped indices. Was trying to write in a mapped
file declared as read only.
modified: storage/connect/xindex.cpp
Fix memory barrier issues on releasing mutexes. We must have a full
memory barrier between releasing a mutex lock and reading its waiters.
This prevents us from missing to release waiters due to reading the
number of waiters speculatively before releasing the lock. If threads
try and wait between us reading the waiters count and releasing the
lock, those threads might stall indefinitely.
Also, we must use proper ACQUIRE/RELEASE semantics for atomic
operations, not ACQUIRE/ACQUIRE.
On Solaris mktime() adds one extra day to tm_mday field and returns appropriate
value for dates 1600-01-01 and earlier. That is 1600-01-01 becomes 1600-01-02.
Solaris mktime manual excerpts:
...
The tm_year member must be for year 1901 or later. Calendar
times before 20:45:52 UTC, December 13, 1901 or after
03:14:07 UTC, January 19, 2038 cannot be represented. Port-
able applications should not try to create dates before
00:00:00 UTC, January 1, 1970 or after 00:00:00 UTC, January
1, 2038.
...
The mktime() function assumes Gregorian dates. Times before
the adoption of the Gregorian calendar will not match his-
torial records.
...
According to manual Mroonga only supports dates and datetimes after 1900:
https://mariadb.com/kb/en/mariadb/about-mroonga/
Technically these tests cover unsupported values and should fail on all
platforms. Disable tests until the problem is fixed upstream.
