innodb_max_dirty_pages_pct_update(),
innodb_max_dirty_pages_pct_lwm_update():
Invoke buf_pool.page_cleaner_wakeup() in order to wake up
buf_flush_page_cleaner. This allows the test innodb.page_cleaner
to run without any occasional timeouts.
The occasional hangs were introduced by
commit 7b1252c03d (MDEV-24278).
The test galera.galera_var_replicate_myisam_on
would trigger an assertion failure "mode() == m_local"
in wsrep-lib/src/client_state.cpp after the merge
of commit 3067ffc58e enabled it.
In commit 1cb218c37c (MDEV-26450)
we introduced the function log_write_and_flush(), which may
compete with log_checkpoint() invoking log_write_flush_to_disk_low()
from another thread.
The assertion n_pending_flushes==1 is too strict.
There is no possibility of a race condition here, because
fil_flush() is protected by fil_system->mutex and the
rest will be protected by log_sys->mutex.
log_write_flush_to_disk_low(), log_write_and_flush():
Relax the assertions to test for a nonzero count.
Also fixes MDEV-24467 Memory not freed after failed INSERT DELAYED
Description:
In case of an error (e.g. data truncation) during mysql_insert()
handling an INSERT DELAYED, the data type specific data in
fields (e.g. Field_blob::value) is not taken over by the delayed
writer thread.
All fields in table_list->table are freed by free_root()
immediately after mysql_insert(). To avoid a memory leak,
we need to free the specific data before exiting mysql_insert()
on error.
The crash happened because my_isalnum() does not support character
sets with mbminlen>1.
The value of "ft_boolean_syntax" is converted to utf8 in do_string_check().
So calling my_isalnum() is combination with "default_charset_info" was wrong.
Adding new parameters (size_t length, CHARSET_INFO *cs) to
ft_boolean_check_syntax_string() and passing self->charset(thd)
as the character set.
Uninitialized ref_pointer_array[] because setup_fields() got empty
fields list. mysql_multi_update() for some reason does that by
substituting the fields list with empty total_list for the
mysql_select() call (looks like wrong merge since total_list is not
used anywhere else and is always empty). The fix would be to return
back the original fields list. But this fails update_use_source.test
case:
--error ER_BAD_FIELD_ERROR
update v1 set t1c1=2 order by 1;
Actually not failing the above seems to be ok.
The other fix would be to keep resolve_in_select_list false (and that
keeps outer context from being resolved in
Item_ref::fix_fields()). This fix is more consistent with how SELECT
behaves:
--error ER_SUBQUERY_NO_1_ROW
select a from t1 where a= (select 2 from t1 having (a = 3));
So this patch implements this fix.
There are two fill_record() functions (lines 8343 and 8618). First one
is used when there are some explicit values, the second one is used
for all implicit values. First one does update_default_fields(), the
second one did not. Added update_default_fields() call to the implicit
version of fill_record().
On deadlock transaction is rolled back (and trx->state is cleared) but
SELECT continued the loop because evaluate_join_record() ignored the
error status returned from lower join evaluation. val_int() does not
return error status so it is checked by thd->is_error().
Test case was created by Thirunarayanan Balathandayuthapani
<thiru@mariadb.com>
* Handle the (rare) case where the ongoing transaction is aborted, if
the ongoing transaction is considered orphaned. This happens if the
node delivers two consecutive primary views with the
* Add ignorable warning to suite.pm
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
- Go back to using $MAJOR_VER instead of hard-coded version strings where
possible.
- Default to 'auto' in NUMJOBS instead of just 1. Will make mysql-test-run
faster.
- Unify autopkgtest with latest version in Debian, use eatmydata to make
mysql-test-run faster.
- Salsa-CI: Remove obsolete 'artifacts: true' as that is the default value.
- Salsa-CI: Clean away obsolete temporary fixes.
- Salsa-CI: Unify with salsa-ci.yml in Debian, including test upgrades
from Bullseye to Debian unstable.
This is a documentation-only patch to refine the description of
binary mode for the mariadb client.
Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>
Note: This patch backports commits 10cd281 and 1755ea4 from 10.3.
10cd281:
Problem:- Some binary data is inserted into the table using
Jconnector. When binlog dump of the data is applied using mysql
client it gives syntax error.
Reason:-
After investigating it turns out to be a issue of mysql client not
able to properly handle \\0 <0 in binary>. In all binary files
where mysql client fails to insert
these 2 bytes are common (0x5c00)
Solution:-
I have changed mysql.cc to include for the possibility that binary
string can have \\0 in it
1755ea4:
Changes on top of Sachin’s patch. Specifically:
1) Refined the parsing break condition to only change the parser’s
behavior for parsing strings in binary mode (behavior of \0 outside
of strings is unchanged).
2) Prefixed binary_zero_insert.test with ‘mysql_’ to more clearly
associate the purpose of the test.
3) As the input of the test contains binary zeros (0x5c00),
different text editors can visualize this sequence differently, and
Github would not display it at all. Therefore, the input itself was
consolidated into the test and created out of hex sequences to make
it easier to understand what is happening.
4) Extended test to validate that the rows which correspond to the
INSERTS with 0x5c00 have the correct binary zero data.
Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>
Changes on top of Sachin’s patch. Specifically:
1) Refined the parsing break condition to only change the parser’s
behavior for parsing strings in binary mode (behavior of \0 outside
of strings is unchanged).
2) Prefixed binary_zero_insert.test with ‘mysql_’ to more clearly
associate the purpose of the test.
3) As the input of the test contains binary zeros (0x5c00),
different text editors can visualize this sequence differently, and
Github would not display it at all. Therefore, the input itself was
consolidated into the test and created out of hex sequences to make
it easier to understand what is happening.
4) Extended test to validate that the rows which correspond to the
INSERTS with 0x5c00 have the correct binary zero data.
Reviewed By:
===========
Andrei Elkin <andrei.elkin@mariadb.com>
Problem:- Some binary data is inserted into the table using Jconnector. When
binlog dump of the data is applied using mysql cleint it gives syntax error.
Reason:-
After investigating it turns out to be a issue of mysql client not able to properly
handle \\\0 <0 in binary>. In all binary files where mysql client fails to insert
these 2 bytes are commom (0x5c00)
Solution:-
I have changed mysql.cc to include for the possibility that binary string can
have \\\0 in it
The test was passing some uninitialized data to libmariadb.
Mostly, the MemorySanitizer wrapper of send() detected that
some bytes were uninitialized.
The test_mdev19838() is for now disabled under MemorySanitizer,
to be fixed in MDEV-26761.
