We introduce simple plugin dependency. A plugin init function may
return HA_ERR_RETRY_INIT. If this happens during server startup when
the server is trying to initialise all plugins, the failed plugins
will be retried, until no more plugins succeed in initialisation or
want to be retried.
This will fix spider init bugs which is caused in part by its
dependency on Aria for initialisation.
The reason we need a new return code, instead of treating every
failure as a request for retry, is that it may be impossible to clean
up after a failed plugin initialisation. Take InnoDB for example, it
has a global variable `buf_page_cleaner_is_active`, which may not
satisfy an assertion during a second initialisation try, probably
because InnoDB does not expect the initialisation to be called
twice.
The idea is to have simple functions that the user can combine to produce
the exact result one wants, whether the user wants JSON object that has
common keys with another JSON object, or same key/value pair etc. So
making simpler function helps here.
We accomplish this by making three separate functions.
1) JSON_OBJECT_FILTER_KEYS(Obj, Arr_keys):
Put keys ( which are basically strings ) in hash, go over the object and
get key one by one. If the key is present in the hash,
add the key-value pair to result.
2) JSON_OBJECT_TO_ARRAY(Obj) : Create a string variable, Go over the json
object, and add each key value pair as an array into the result.
3) JSON_ARRAY_INTERSECT(arr1, arr2) :
Go over one of the json and add each item of the array
in hash (after normalizing each item). Go over the second array,
search the normalized item one by one in the hash. If item is found,
add it to the result.
15a7b6c...
by
Rucha Deodhar <email address hidden>
MDEV-30145: JSON_TABLE: allow to retrieve the key when iterating on JSON
objects
Idea behind implementation:
We get the json object specified by the json path. Then, transform it into
key-value pairs by going over the json. Get each key-value pair
one-by-one and return the result.
MDEV-31714 Debian 50-mariadb_safe.cnf has syslog enabled
50-mariadb_safe.cnf was only ever intended to be a reference file.
With mariadbd-safe falling into disuse in Debian since systemd became
a service it was assumed this files wasn't used except on a few old
legacy init systems. Its assumed these users will have a configuration
already set.
It is however read by the mariabackup galera-sst script. This forks
off the logger process to write the output to /dev/log, which on a
systemd service the journalctl is reading anyway.
The real harm is on containers where there is now a MariaDB operator
that runs Galera based containers. In containers there is no /dev/log,
so information gets lost.
It would be much more direct just to go straight to stdout/error
like what would happen without this configuration.
Rather than risk the galera-sst scripts moving to the [mariadbd-safe]
group name introduced in a1211a4eda9c7348295ce4a6fdfa8e94860e5e14, we
remove the file for cleanness.
2992d53...
by
Dmitry Shulga <email address hidden>
This is the follow-up patch for the task MDEV-5816 that fixes assert failure
that happened after recompilation of a stored routine containing a cursor
on its second execution.
The reason of assertion hit is that a state of the SP instruction sp_instr_cpush
wasn't reset after its SQL statement re-compiled.
To fix the issue the virtual method sp_lex_instr::on_after_expr_parsing
is overridden in the derived class sp_instr_cpush. Implementation of this method
does resetting of the data member sp_instr_cpush::m_metadata_changed
Additionally, implementation of the method
sp_instr_set_trigger_field::on_after_expr_parsing
has been slightly modified to set the data member
sp_instr_set_trigger_field::value
just before successful return. This data member is used to check whether this
SP instruction is still valid or should be re-compiled.
Resetting this data member before an instance of the class Item_trigger_field
be successfully allocated theoretically could lead to clearing of instruction's
state despite the fact that memory allocation was failed.
856196e...
by
Dmitry Shulga <email address hidden>
MDEV-5816: fixes for --view
view creation (that mysqltest automatically does in --view protocol)
can cause sp cache invalidation, and that will cause the test to fail
(because the test checks that invalidation did not happen).
disable view protocol in the parts of the test where this is the case
Author: Sergei Golubchik
3a8e769...
by
Dmitry Shulga <email address hidden>
DEV-5816: Stored programs: validation of stored program statements
The follow-up patch to check in mtr tests that recompilation of
a SP's instruction doesn't lead to eviction of SP from sp_cache.
This patch adds the debug keyword 'check_sp_cache_not_invalidated'
checked in sp_cache_flush_obsolete. In case this debug keyword
is set the macros DBUG_SUICIDE() called to cause test failure.
The function sp_cache_flush_obsolete() is called on opening
a stored routine. So setting this keyword before second execution
of some stored routine that supposed to cause recompilation of
SP's statement will guarantee that this stored routine not evicted
from sp_cache.
Suggested approach has one limitation - the statement
CREATE/ALTER/DROP VIEW
forces invalidation of the whole sp_cache (by invoking the function
sp_cache_invalidate()).
So, for those tests (actually, there are very small number of such tests)
that create/alter/drop a view before the second execution of some stored
routine, the debug keyword 'check_sp_cache_not_invalidated' isn't set.
The proposal to add some way a check that a stored routine is not force out
from sp_cache on re-parsing a failing statement of a stored routine was
done during reiew, that is the reason the proposed change has been formatted
as a separate patch.
8a3c62c...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Added mtr tests for MDEV-5816
ec04357...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
