In a test case Update occurs between Search and Delete/Update. This corrupts rowid
which Search saves for Delete/Update. Patch prevents this by using of
HA_EXTRA_REMEMBER_POS and HA_EXTRA_RESTORE_POS in a partition code.
This situation possibly occurs only with system versioning table and partition.
MyISAM and Aria engines are affected.
fix by midenok
Closes#705
order with Galera and encrypt-tmp-files=1
Problem:- If trans_cache (IO_CACHE) uses encrypted tmp file
then on next DML server will crash.
Case:-
Lets take a case , we have a table t1 , We try to do 2 inserts in t1
1. A really long insert so that trans_cache has to use temp_file
2. Just a small insert
Analysis:- Actually server crashes from inside of galera
library.
/lib64/libc.so.6(abort+0x175)[0x7fb5ba779dc5]
/usr/lib64/galera/libgalera_smm.so(_ZN6galera3FSMINS_9TrxHandle5State...
mysys/stacktrace.c:247(my_print_stacktrace)[0x7fb5a714940e]
sql/signal_handler.cc:160(handle_fatal_signal)[0x7fb5a715c1bd]
sql/wsrep_hton.cc:257(wsrep_rollback)[0x7fb5bcce923a]
sql/wsrep_hton.cc:268(wsrep_rollback)[0x7fb5bcce9368]
sql/handler.cc:1658(ha_rollback_trans(THD*, bool))[0x7fb5bcd4f41a]
sql/handler.cc:1483(ha_commit_trans(THD*, bool))[0x7fb5bcd4f804]
but actual issue is not in galera but in mariadb, because for 2nd
insert we should never call rollback. We are calling rollback because
log_and_order fails it fails because write_cache fails , It fails
because after reinit_io_cache(trans_cache) , my_b_bytes_in_cache says 0
so we look into tmp_file for data , which is obviously wrong since temp
was used for previous insert and it no longer exist.
wsrep_write_cache_inc() reads the IO_CACHE in a loop, filling it with
my_b_fill() until it returns "0 bytes read". Later
MYSQL_BIN_LOG::write_cache() does the same. wsrep_write_cache_inc()
assumes that reading a zero bytes past EOF leaves the old data in the
cache
Solution:- There is two issue in my_b_encr_read
1st we should never equal read_end to info->buffer. I mean this
does not make sense read_end should always point to end of buffer.
2nd For most of the case(apart from async IO_CACHE) info->pos_in_file
should be equal to info->buffer position wrt to temp file , since
in this case we are not changing info->buffer it should remain
unchanged.
The failures with valgrind occur as a result of Spider sometimes using the
wrong transaction for operations in background threads that send requests to
the data nodes. The use of the wrong transaction caused the networking to the
data nodes to use the wrong thread in some cases. Valgrind eventually
detects this when such a thread is destroyed before it is used to disconnect
from the data node by that wrong transaction when it is freed.
I have fixed the problem by correcting the transaction used in each of these
cases.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Cherry-Picked:
Commit afe5a51 on branch 10.2
The failures with valgrind occur as a result of Spider sometimes using the
wrong transaction for operations in background threads that send requests to
the data nodes. The use of the wrong transaction caused the networking to the
data nodes to use the wrong thread in some cases. Valgrind eventually
detects this when such a thread is destroyed before it is used to disconnect
from the data node by that wrong transaction when it is freed.
I have fixed the problem by correcting the transaction used in each of these
cases.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Merged:
Commit 4d576d9 on branch bb-10.3-MDEV-12900
The failures with valgrind occur as a result of Spider sometimes using the
wrong transaction for operations in background threads that send requests to
the data nodes. The use of the wrong transaction caused the networking to the
data nodes to use the wrong thread in some cases. Valgrind eventually
detects this when such a thread is destroyed before it is used to disconnect
from the data node by that wrong transaction when it is freed.
I have fixed the problem by correcting the transaction used in each of these
cases.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Merged:
Commit 4d576d9 on branch bb-10.3-MDEV-12900
The failures with valgrind occur as a result of Spider sometimes using the
wrong transaction for operations in background threads that send requests to
the data nodes. The use of the wrong transaction caused the networking to the
data nodes to use the wrong thread in some cases. Valgrind eventually
detects this when such a thread is destroyed before it is used to disconnect
from the data node by that wrong transaction when it is freed.
I have fixed the problem by correcting the transaction used in each of these
cases.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
- Using array_elements() instead of a constant to iterate through an array
- Adding some comments
- Adding new-line function comments
- Using STRING_WITH_LEN instead of C_STRING_WITH_LEN
don't rely on imprecise my_file_opened | my_stream_opened,
scan the array for open handles instead.
also, remove my_print_open_files() and embed it in my_end()
to have one array scan instead of two.
Change the following to statistic counters:
* my_file_opened
* my_file_total_opened
* my_stream_opened
* my_tmp_file_created
There is one non-statistics use of my_file_opened/my_stream_opened
in my_end which prints a warning if we shutdown and its still open.
It seems excessive to hold locks to prevent this warning.
A file descriptor is already a unique element per process - in Windows,
protection occurs at fd allocation using THR_LOCK_open in my_win_{,f}open
and in other OSes, a unique fd to file map exists at the OS level.
So accesses to my_file_info[fd] don't need to be protected by the
THR_LOCK_open.
my_close/my_fclose where restructured to clear out the my_file_info
before the close/my_win_close/my_win_fclose. After these calls another
thread could gain the same file descriptor. So for Windows this
the file_info elements available to the my_win_{,f}_open are released
during the invalidate_fd call within my_win_close. No locking is needed
as the my_win_{,f}open is searching for a invalidate entry which is
determined by a single value change.
my_fclose also changed for non-Windows to retry closing if EINTR was
returned, same as my_close.
Closes#657
simplify. move common code inside, specify common flags inside,
rewrite dead code (`if (mode & O_TEMPORARY)` on Linux, where
`O_TEMPORARY` is always 0) to actually do something.
for consistency with EVP_CIPHER_CTX_new() and EVP_CIPHER_CTX_free().
As the EVP_DIGESTINIT(3) man page says:
EVP_MD_CTX_create() and EVP_MD_CTX_destroy() were renamed to
EVP_MD_CTX_new() and EVP_MD_CTX_free() in OpenSSL 1.1.
Closes#621
don't rely on imprecise my_file_opened | my_stream_opened,
scan the array for open handles instead.
also, remove my_print_open_files() and embed it in my_end()
to have one array scan instead of two.
Change the following to statistic counters:
* my_file_opened
* my_file_total_opened
* my_stream_opened
* my_tmp_file_created
There is one non-statistics use of my_file_opened/my_stream_opened
in my_end which prints a warning if we shutdown and its still open.
It seems excessive to hold locks to prevent this warning.
A file descriptor is already a unique element per process - in Windows,
protection occurs at fd allocation using THR_LOCK_open in my_win_{,f}open
and in other OSes, a unique fd to file map exists at the OS level.
So accesses to my_file_info[fd] don't need to be protected by the
THR_LOCK_open.
my_close/my_fclose where restructured to clear out the my_file_info
before the close/my_win_close/my_win_fclose. After these calls another
thread could gain the same file descriptor. So for Windows this
the file_info elements available to the my_win_{,f}_open are released
during the invalidate_fd call within my_win_close. No locking is needed
as the my_win_{,f}open is searching for a invalidate entry which is
determined by a single value change.
my_fclose also changed for non-Windows to retry closing if EINTR was
returned, same as my_close.
Closes#657
simplify. move common code inside, specify common flags inside,
rewrite dead code (`if (mode & O_TEMPORARY)` on Linux, where
`O_TEMPORARY` is always 0) to actually do something.
for consistency with EVP_CIPHER_CTX_new() and EVP_CIPHER_CTX_free().
As the EVP_DIGESTINIT(3) man page says:
EVP_MD_CTX_create() and EVP_MD_CTX_destroy() were renamed to
EVP_MD_CTX_new() and EVP_MD_CTX_free() in OpenSSL 1.1.
Closes#621
- Using array_elements() instead of a constant to iterate through an array
- Adding some comments
- Adding new-line function comments
- Using STRING_WITH_LEN instead of C_STRING_WITH_LEN
don't rely on imprecise my_file_opened | my_stream_opened,
scan the array for open handles instead.
also, remove my_print_open_files() and embed it in my_end()
to have one array scan instead of two.
