Last commit made on 2019-04-04
Get this branch:
git clone -b bb-5.5-wlad

Branch merges

Branch information


Recent commits

6d4744c... by Vladislav Vaintroub on 2019-04-04

MDEV-17610 Unexpected connection abort after certain operations from within stored procedure

Always set SERVER_MORE_RESULTS_EXIST when executing stored procedure statements

If statements produce a result, EOF packet needs this flag (SP ends
with an OK packet). IF statetement does not produce a result, affected rows
count are part of the final OK packet.

f2d549d... by Sujatha Sivakumar <email address hidden> on 2019-03-27

MDEV-14784: Slave crashes in show_status_array upon running a trigger with
select from I_S

When applier thread tries to access 'variable_name' of
INFORMATION_SCHEMA.SESSION_VARIABLES table through triggers, it results in an
abnormal exit of slave server.

At the time of replication of stored routines and triggers, their associated
security context will be sent by the master. The applier thread on the slave
server will use this information to set the required security context for the
execution of stored routines and triggers. This is achieved as follows.

->The stored routine object has a member named 'm_security_ctx' which holds the
  security context received from master.
->The applier thread's security_ctx is stored into a 'backup' object.

->Set the applier thread's security_ctx to 'm_security_ctx'.

->Upon the completion of stored routine execution restore the original security
  context of applier thread from the backup.

During the above process the 'm_security_ctx' object is not initialized
properly. Hence the 'external_user' of 'm_security_ctx' has invalid value for
this variable and accessing this variable results in abnormal exit of server.

Invoke the Security_context::init() call from the constructor of stored routine
so that 'm_security_ctx' gets initialized properly.

e890711... by Sergey Vojtovich on 2019-03-25

Fixed ps-protocol thread_pool_server_audit failure

By applying 7bd258c.

cfe0fe1... by Bernhard M. Wiedemann on 2019-01-26

Fix tests in 2020

unfortunately, the year 2038 problem prevented me from pushing
the deadline even further into the future.

c61e8a6... by Chris Calender on 2019-03-24

Fix for MDEV-17449, typo in error message (#1146)

d8b7e76... by Chris Calender <email address hidden> on 2019-02-07

Fix for MDEV-18276, typo in error message + all other occurrences of refering

778c525... by Sachin Setiya on 2019-03-20

MDEV-17119 replicate_rewrite_db does not work for single chardatabase name

Fixed issue in logic.

f00e25b... by Chris Calender on 2019-02-10

Fix for MDEV-15538, '-N' Produce html output wrong

0dd12b4... by Igor Babaev on 2019-03-15

MDEV-18896 Crash in convert_join_subqueries_to_semijoins

If an IN-subquery is used in a table-less select the current code
should never consider it as candidate for semi-join optimizations.
Yet the function check_and_do_in_subquery_rewrites() improperly
checked the property "to be a table-less select". As a result
such select in IN subquery was used in INSERT .. SELECT then
the IN subquery by mistake was registered as a semi-join subquery
and convert_subq_to_sj() was called for it. However the code of
this function does not assume that the parent select of the subquery
could be a table-less select.

8024f8c... by Marko Mäkelä on 2019-03-07

MDEV-18272 InnoDB fails to rollback after exceeding FOREIGN KEY recursion depth

row_mysql_handle_errors(): Correct the wrong error handling for
the code DB_FOREIGN_EXCEED_MAX_CASCADE that was introduced in

    commit 35f5429eda94f2ce87e453653cd22298d5851cfa
    Author: Jimmy Yang <email address hidden>
    Date: Wed Oct 6 06:55:34 2010 -0700

        Manual port Bug #Bug #54582 "stack overflow when opening many tables
        linked with foreign keys at once" from mysql-5.1-security to
        mysql-5.5-security again.

        rb://391 approved by Heikki

No known test case exists for repeating the bug before MariaDB 10.2.
The scenario should be that DB_FOREIGN_EXCEED_MAX_CASCADE is returned,
then InnoDB wrongly skips the rollback to the start of the current
row operation, and finally the SQL layer commits the transaction.
Normally the SQL layer would roll back either the entire transaction or
to the start of the statement. In the faulty scenario, InnoDB would
leave the transaction in an inconsistent state, and the SQL layer could
commit the transaction.