given an already connected MYSQL handle
mysql_real_connect() did not check whether the MYSQL connection
handler was already connected and connected again even if so.
Now a CR_ALREADY_CONNECTED error is returned.
2677 Vladislav Vaintroub 2008-11-04
CMakeLists.txt files cleanup
- remove SAFEMALLOC and SAFE_MUTEX definitions that were
present in *each* CMakeLists.txt. Instead, put them into top level
CMakeLists.txt, but disable on Windows, because
a) SAFEMALLOC does not add any functionality that is not already
present in Debug C runtime ( and 2 safe malloc one on top of the other
only unnecessarily slows down the server)
b)SAFE_MUTEX does not work on Windows and have been
explicitely disabled on Windows with #undef previously. Fortunately,
ntdll does pretty good job identifying l problems with
CRITICAL_SECTIONs.
DebugBreak()s on using uninited critical section, unlocking unowned
critical section)
-Also, remove occationally used -D_DEBUG (added by compiler
anyway)
http://lists.mysql.com/commits/57725
Vladislav Vaintroub 2008-11-03
Cleanup CMakeLists.txt(s) - remove winsock2 (ws2_32) from
TARGET_LINK_LIBRARIES.
Every exe or dll linked with mysys needs ws2_32, because
mysys uses winsock function WSAStartup in my_init().
However, there is no need to explicitely add ws2_32 to
the list of TARGET_LINK_LIBRARIES multiple times.
Visual Studio comes with a handy pragma that tells linker
to add library. So patch replaces bunch of ws2_32 in
CMakeLists with single pragma comment(lib,"ws2_32")
in my_init.c
Additionally, reference to non-existing "debug" library
has been removed from TARGET_LINK_LIBRARIES. The correct
name of the library is "dbug".
htttp://lists.mysql.com/commits/50957?f=plain
Always use TLS functions instead of __declspec(thread) to access
thread local storage variables.
The change removes the necessity to recomplile the same source
files twice - with USE_TLS for DLLs and without USE_TLS for EXEs.
Real benefit of this change is better readability and maintainability
of TLS functions within MySQL.
There is a performance loss using TlsXXX functions compared to __declspec
but the difference is negligible in practice. In a sysbench-like benchmark
I ran with with TlsGetValue, pthread_[get|set]_specific was called 600000000
times and took 0.17sec of total 35min CPU time, or 0.008%.
The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).
The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.
Post-merge fix: test case could fail due to a conversion of the
max_join_size value to a integer. Fixed by preserving the value
as a string for comparison purposes.
unnecessarily
The problem is that libmysqlclient.so is built with THREAD
undefined, while a client compiling against the same header
files will see THREAD as defined and definitions in
my_pthread.h will be included, possibly resulting in undefined
symbols that cannot be resolved with libmysqlclient.so.
The suggested solution is to require that clients wanting to
link with libmysqlclient.so should be built with
MYSQL_CLIENT_NO_THREADS defined. This requires a documentation
change, and more details for this will be supplied if this
patch is approved.
The MYSQL_CLIENT_NO_THREADS define was renamed from
UNDEF_THREADS_HACK, to get a more suitable (less suspicious)
name for the define. (The UNDEF_THREADS_HACK is retained for
backwards compatibility, though.)
This patch is also in anticipation of WL#4958, which will
remove this problem altogether by dropping the building of
libmysqlclient.
without proper formatting
The problem is that a suitably crafted database identifier
supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
and thereby a denial of service. The database name is printed
to the log without using a format string, so potential
attackers can control the behavior of my_b_vprintf() by
supplying their own format string. A CREATE or DROP privilege
would be required.
This patch supplies a format string to the printing of the
database name. A test case is added to mysql_client_test.
per-file comments:
tests/mysql_client_test.c
the test for bug 37956 isn't relevant anymore.
The query there 'select point(?,?)' doesn't produce an error.
This is a back port from 5.1 to 5.0.
Fix for BUG 20023: mysql_change_user() resets the value
of SQL_BIG_SELECTS.
The bug was that SQL_BIG_SELECTS was not properly set
in COM_CHANGE_USER.
The fix is to update SQL_BIG_SELECTS properly.
*with --with-charset=utf8*
Problem: wrong LONG TEXT field length is sent to a client
when multibyte server character set used.
Fix: always limit field length sent to a client to 2^32,
as we store it in 4 byte slot.
Note: mysql_client_test changed accordingly.
returns short string value.
Multibyte character sets were not taken into account when
calculating max_length in Item_param::convert_str_value(). As a
result, string parameters of a prepared statement could be
truncated later when calculating string length in characters by
dividing length in bytes by the charset's mbmaxlen value (e.g. in
Field_varstring::store()).
Fixed by taking charset's mbmaxlen into account when calculating
max_length in Item_param::convert_str_value().
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
The problem is that the query cache stores packets containing
the server status of the time when the cached statement was run.
This might lead to a wrong transaction status in the client side
if a statement is cached during a transaction and is later served
outside a transaction context (and vice-versa).
The solution is to take into account the transaction status when
storing in and serving from the query cache.
Bug#37671 crash on prepared statement + cursor + geometry + too many open files!
if mysql_execute_command() returns error then free materialized_cursor object.
is_rnd_inited is added to satisfy rnd_end() assertion
(handler may be uninitialized in some cases)
The code to get read the value of a system variable was extracting its value
on PREPARE stage and was substituting the value (as a constant) into the parse tree.
Note that this must be a reversible transformation, i.e. it must be reversed before
each re-execution.
Unfortunately this cannot be reliably done using the current code, because there are
other non-reversible source tree transformations that can interfere with this
reversible transformation.
Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the
functions operate). Added a cache of the value (so that it's constant throughout
the execution of the query). Note that the cache also caches NULL values.
Updated an obsolete related test suite (variables-big) and the code to test the
result type of system variables (as per bug 74).
