1
0
mirror of https://github.com/MariaDB/server.git synced 2025-05-07 04:01:59 +03:00

833 Commits

Author SHA1 Message Date
Konstantin Osipov
88f7de578b Backport of:
------------------------------------------------------------
revno: 2476.657.208
committer: anozdrin/alik@station.
timestamp: Tue 2007-12-04 17:22:53 +0300
message:
Remove rpl_probe, enable_rpl_parse and disable_rpl_parse commands
from mysqltest, the corresponding funtctions have been removed from
MySQL C API
2009-10-16 01:11:42 +04:00
Konstantin Osipov
ded234de1e Backport of:
------------------------------------------------------------
revno: 2476.981.1
committer: msvensson@pilot.mysql.com
timestamp: Mon 2007-11-26 19:03:23 +0100
message:
  Bug#31952 Remove undocumented mysql_rpl_* functions.
  - Functions removed + variables in st_mysql and st_mysql_options 
    renamed to "unused".
  - Code updated to work without those functions and variables
2009-10-16 00:56:17 +04:00
Konstantin Osipov
16218fe5b0 Backport of:
------------------------------------------------------------
revno: 2476.981.1
committer: msvensson@pilot.mysql.com
timestamp: Mon 2007-11-26 19:03:23 +0100
message:
  Bug#31952 Remove undocumented mysql_rpl_* functions.
  - Functions removed + variables in st_mysql and st_mysql_options 
    renamed to "unused".
  - Code updated to work without those functions and variables
2009-10-16 00:56:17 +04:00
Magne Mahre
c9248c6424 Bug #33831 mysql_real_connect() connects again if
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.
2009-10-09 14:30:54 +02:00
Magne Mahre
63350dfc8b Bug #33831 mysql_real_connect() connects again if
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.
2009-10-09 14:30:54 +02:00
He Zhenxing
9739efbfec Backport BUG#25192 Using relay-log and relay-log-index without values produces unexpected results.
Options loaded from config files were added before command line
arguments, and they were parsed together, which could interprete
the following:
option-a
option-b
as --option-a=--option-b if 'option-a' requires a value, and 
caused confusing.

Because all options that requires a value are always given in
the form '--option=value', so it's an error if there is no 
'=value' part for such an option read from config file.

This patch added a separator to separate the arguments from 
config files and that from command line, so that they can be
handled differently. And report an error for options loaded
from config files that requires a value and is not given in the
form '--option=value'.
2009-10-02 16:25:53 +08:00
He Zhenxing
86c36aa1fd Backport BUG#25192 Using relay-log and relay-log-index without values produces unexpected results.
Options loaded from config files were added before command line
arguments, and they were parsed together, which could interprete
the following:
option-a
option-b
as --option-a=--option-b if 'option-a' requires a value, and 
caused confusing.

Because all options that requires a value are always given in
the form '--option=value', so it's an error if there is no 
'=value' part for such an option read from config file.

This patch added a separator to separate the arguments from 
config files and that from command line, so that they can be
handled differently. And report an error for options loaded
from config files that requires a value and is not given in the
form '--option=value'.
2009-10-02 16:25:53 +08:00
Ingo Struewing
1f49cf7409 auto-merge 2009-09-30 12:30:09 +02:00
Ingo Struewing
309ffb8b13 auto-merge 2009-09-30 12:30:09 +02:00
Ingo Struewing
7dacca0ff0 Bug#37267 - connect() EINPROGRESS failures mishandled in client library
We cann connect() in a non-blocking mode to be able to specify a
non-standard timeout.

The problem was that we did not fetch the status from the
non-blocking connect(). We assumed that poll() would not return
a POLLIN flag if the connect failed. But on some platforms this
is not true.

After a successful poll() we do now retrieve the status value
from connect() with getsockopt(...SO_ERROR...). Now we do know
if (and how) the connect failed.

The test case for my investigation was rpl.rlp_ssl1 on an
Ubuntu 9.04 x86_64 machine. Both, IPV4 and IPV6 were active.
'localhost' resolved first for IPV6 and then for IPV4. The
connection over IPV6 was blocked. rpl.rlp_ssl1 timed out
as it did not notice the failed connect(). The first read()
failed, which was interpreted as a master crash and the
connection was tried to reestablish with the same result
until the retry limit was reached.

With the fix, the connect() problem is immediately recognized,
and the connect() is retried on the second resolution for
'localhost', which is successful.


libmysqld/libmysqld.c:
  Bug#37267 - connect() EINPROGRESS failures mishandled in client library
  Changed a DBUG print string to distinguish the two mysql_real_connect()
  implementations in DBUG traces.
mysql-test/include/wait_for_slave_param.inc:
  Bug#37267 - connect() EINPROGRESS failures mishandled in client library
  Made timeout value available in error message.
mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
  Bug#37267 - connect() EINPROGRESS failures mishandled in client library
  Fixed test result. Connect error is now detected as CR_CONN_HOST_ERROR
  (2003) instead of CR_SERVER_LOST (2013).
sql-common/client.c:
  Bug#37267 - connect() EINPROGRESS failures mishandled in client library
  Added retrieval of the error code from the non-blocking connect().
  Added DBUG.
  Added comment.
2009-09-30 12:28:15 +02:00
Ingo Struewing
1e87babb19 Bug#37267 - connect() EINPROGRESS failures mishandled in client library
We cann connect() in a non-blocking mode to be able to specify a
non-standard timeout.

The problem was that we did not fetch the status from the
non-blocking connect(). We assumed that poll() would not return
a POLLIN flag if the connect failed. But on some platforms this
is not true.

After a successful poll() we do now retrieve the status value
from connect() with getsockopt(...SO_ERROR...). Now we do know
if (and how) the connect failed.

The test case for my investigation was rpl.rlp_ssl1 on an
Ubuntu 9.04 x86_64 machine. Both, IPV4 and IPV6 were active.
'localhost' resolved first for IPV6 and then for IPV4. The
connection over IPV6 was blocked. rpl.rlp_ssl1 timed out
as it did not notice the failed connect(). The first read()
failed, which was interpreted as a master crash and the
connection was tried to reestablish with the same result
until the retry limit was reached.

With the fix, the connect() problem is immediately recognized,
and the connect() is retried on the second resolution for
'localhost', which is successful.
2009-09-30 12:28:15 +02:00
Guilhem Bichot
12e822039d Fix for BUG#42980 "Client doesn't set NUM_FLAG for DECIMAL and TIMESTAMP":
DECIMAL and TIMESTAMP used to have NUM_FLAG, but NEWDECIMAL was forgotten.
It's correct that TIMESTAMP does not have the flag nowadays (manual will be updated, connectors
developers will be notified).

client/mysqldump.c:
  IS_NUM_FIELD(f) removed and replaced by its definition (f>flags & NUM_FLAG).
include/mysql.h:
  - IS_NUM_FIELD() is removed because name is too close to IS_NUM() and it is not used a lot
  - INTERNAL_NUM_FIELD() is removed:
    * it forgets to test NEWDECIMAL (when IS_NUM() was updated for NEWDECIMAL we forgot
    to update INTERNAL_NUM_FIELD()), that's why client didn't mark NEWDECIMAL with NUM_FLAG (a bug).
    * it has an obsolete test for length of the TIMESTAMP field: test became accidentally wrong when length
    of TIMESTAMP was changed to always be 19 (when the format was changed from YYYYMMDDhhmmss to
    YYYY-MM-DD hh:mm:ss), never 8 or 14 anymore. That obsolete test caused TIMESTAMP to lose NUM_FLAG,
    which was an accidental but good change (see below).
    * IS_NUM() should be used instead
  - IS_NUM(f) is changed: TIMESTAMP used to be parsable as a number without quotes (when it was formatted as
  "YYYYMMDDhhmmss"); but it is not anymore (now that it is "YYYY-MM-DD hh:mm:ss"), so it should not have NUM_FLAG
  (mysqldump needs to quote TIMESTAMP values), so IS_NUM() should return false for it.
libmysqld/lib_sql.cc:
  use IS_NUM() instead of INTERNAL_NUM_FIELD()
mysql-test/r/bigint.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/r/metadata.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/r/mysqldump.result:
  DECIMAL columns are not quoted anymore by mysqldump. Which is ok, the parser does not need '' for them
mysql-test/r/ps_2myisam.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/r/ps_3innodb.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/r/ps_4heap.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/r/ps_5merge.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/suite/ndb/r/ps_7ndb.result:
  result change: NEWDECIMAL fields now have NUM_FLAG (32768)
mysql-test/t/metadata.test:
  test for BUG#42980
sql-common/client.c:
  use IS_NUM() instead of INTERNAL_NUM_FIELD()
2009-09-30 12:25:50 +02:00
Guilhem Bichot
b3886f46da Fix for BUG#42980 "Client doesn't set NUM_FLAG for DECIMAL and TIMESTAMP":
DECIMAL and TIMESTAMP used to have NUM_FLAG, but NEWDECIMAL was forgotten.
It's correct that TIMESTAMP does not have the flag nowadays (manual will be updated, connectors
developers will be notified).
2009-09-30 12:25:50 +02:00
Sergey Petrunya
29f0dcb563 Merge MySQL->MariaDB
* Finished Monty and Jani's merge
* Some InnoDB tests still fail (because it's old xtradb code run against
  newer testsuite). They are expected to go after mergning with the latest
  xtradb.
2009-09-08 00:50:10 +04:00
Tatiana A. Nurnberg
cf69196922 manual merge 2009-08-31 12:40:33 -07:00
Tatiana A. Nurnberg
e8d45e1be7 manual merge 2009-08-31 12:40:33 -07:00
Tatiana A. Nurnberg
d85148d84c Bug#35132: MySQLadmin --wait ping always crashes on Windows systems
Failing to connect would release parts of the MYSQL struct.
We would then proceed to try again to connect without re-
initializing the struct.

We prevent the unwanted freeing of data we'll still need now.


client/mysqladmin.cc:
  Losing a connection (or not even getting on in the first place) should
  not trash the MYSQL-struct.
  
  Add a lot of comments.
  
  Rewrite re-connection fu.
sql-common/client.c:
  Assert against bad parameters usually caused by de-initing a
  MYSQL-struct without re-initing it again before re-use.
2009-08-31 10:01:13 -07:00
Tatiana A. Nurnberg
c3aac11c08 Bug#35132: MySQLadmin --wait ping always crashes on Windows systems
Failing to connect would release parts of the MYSQL struct.
We would then proceed to try again to connect without re-
initializing the struct.

We prevent the unwanted freeing of data we'll still need now.
2009-08-31 10:01:13 -07:00
Staale Smedseng
5be4c38226 Merge from 5.0 for 43414 2009-08-28 18:21:54 +02:00
Staale Smedseng
f59ef9eafa Merge from 5.0 for 43414 2009-08-28 18:21:54 +02:00
Staale Smedseng
1ba25ae47c Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
      
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.


client/mysqlmanager-pwgen.c:
  A fix for warn_unused_result, adding fallback to use of
  srand()/rand() if /dev/random cannot be used. Also actually
  adds calls to rand() in the second branch so that it actually
  creates a random password.
2009-08-28 17:51:31 +02:00
Staale Smedseng
2217de2513 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
      
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.
2009-08-28 17:51:31 +02:00
Davi Arnaut
050c36c7de Bug#46013: rpl_extraColmaster_myisam fails on pb2
Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
Bug#45242: crash on win in mysql_close() -> free()
Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
Bug#46030: rpl_truncate_3innodb causes server crash on windows
Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2

When killing a user session on the server, it's necessary to
interrupt (notify) the thread associated with the session that
the connection is being killed so that the thread is woken up
if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
procedure is to asynchronously close the underlying socket of
the connection.

In order to enable this schema, each connection serving thread
registers its VIO (I/O interface) so that other threads can
access it and close the connection. But only the owner thread of
the VIO might delete it as to guarantee that other threads won't
see freed memory (the thread unregisters the VIO before deleting
it). A side note: closing the socket introduces a harmless race
that might cause a thread attempt to read from a closed socket,
but this is deemed acceptable.

The problem is that this infrastructure was meant to only be used
by server threads, but the slave I/O thread was registering the
VIO of a mysql handle (a client API structure that represents a
connection to another server instance) as a active connection of
the thread. But under some circumstances such as network failures,
the client API might destroy the VIO associated with a handle at
will, yet the VIO wouldn't be properly unregistered. This could
lead to accesses to freed data if a thread attempted to kill a
slave I/O thread whose connection was already broken.

There was a attempt to work around this by checking whether
the socket was being interrupted, but this hack didn't work as
intended due to the aforementioned race -- attempting to read
from the socket would yield a "bad file descriptor" error.

The solution is to add a hook to the client API that is called
from the client code before the VIO of a handle is deleted.
This hook allows the slave I/O thread to detach the active vio
so it does not point to freed memory.

server-tools/instance-manager/mysql_connection.cc:
  Add stub method required for linking.
sql-common/client.c:
  Invoke hook.
sql/client_settings.h:
  Export hook.
sql/slave.cc:
  Introduce hook that clears the active VIO before it is freed
  by the client API.
2009-08-13 17:07:20 -03:00
Davi Arnaut
97dbd987f0 Bug#46013: rpl_extraColmaster_myisam fails on pb2
Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
Bug#45242: crash on win in mysql_close() -> free()
Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
Bug#46030: rpl_truncate_3innodb causes server crash on windows
Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2

When killing a user session on the server, it's necessary to
interrupt (notify) the thread associated with the session that
the connection is being killed so that the thread is woken up
if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
procedure is to asynchronously close the underlying socket of
the connection.

In order to enable this schema, each connection serving thread
registers its VIO (I/O interface) so that other threads can
access it and close the connection. But only the owner thread of
the VIO might delete it as to guarantee that other threads won't
see freed memory (the thread unregisters the VIO before deleting
it). A side note: closing the socket introduces a harmless race
that might cause a thread attempt to read from a closed socket,
but this is deemed acceptable.

The problem is that this infrastructure was meant to only be used
by server threads, but the slave I/O thread was registering the
VIO of a mysql handle (a client API structure that represents a
connection to another server instance) as a active connection of
the thread. But under some circumstances such as network failures,
the client API might destroy the VIO associated with a handle at
will, yet the VIO wouldn't be properly unregistered. This could
lead to accesses to freed data if a thread attempted to kill a
slave I/O thread whose connection was already broken.

There was a attempt to work around this by checking whether
the socket was being interrupted, but this hack didn't work as
intended due to the aforementioned race -- attempting to read
from the socket would yield a "bad file descriptor" error.

The solution is to add a hook to the client API that is called
from the client code before the VIO of a handle is deleted.
This hook allows the slave I/O thread to detach the active vio
so it does not point to freed memory.
2009-08-13 17:07:20 -03:00
Davi Arnaut
543e86728f Bug#45017: Failure to connect if hostname maps to multiple addresses
The problem is that the C API function mysql_real_connect
only attempts to connect to the first IP address returned
for a hostname. This can be a problem if a hostname maps
to multiple IP address and the server is not bound to the
first one that is returned.

The solution is to augment mysql_real_connect so that it
attempts to connect to all IPv4 addresses that a domain
name maps to. The function goes over the list of address
until a successful connection is established.

No test case is provided as its not possible to test this
automatically with the current testing infrastructure.

sql-common/client.c:
  The client will try to connect to each IPv4 address from
  the list of addresses that hostname maps to until a successful
  connection is established or there are no more address.
2009-07-30 21:28:43 -03:00
Davi Arnaut
1c2556ff46 Merge from mysql-5.0-bugteam. 2009-08-13 17:45:01 -03:00
Davi Arnaut
1cf02d95a7 Merge from mysql-5.0-bugteam. 2009-08-13 17:45:01 -03:00
Davi Arnaut
35e5b9b8c9 Bug#45017: Failure to connect if hostname maps to multiple addresses
The problem is that the C API function mysql_real_connect
only attempts to connect to the first IP address returned
for a hostname. This can be a problem if a hostname maps
to multiple IP address and the server is not bound to the
first one that is returned.

The solution is to augment mysql_real_connect so that it
attempts to connect to all IPv4 addresses that a domain
name maps to. The function goes over the list of address
until a successful connection is established.

No test case is provided as its not possible to test this
automatically with the current testing infrastructure.
2009-07-30 21:28:43 -03:00
unknown
e84748406c Fix memory leak in mysql_ssl_set() when called more than once.
Fix sleep() synchronisation in innodb_information_schema test case.

mysql-test/t/innodb_information_schema.test:
  Using sleep for synchronisation does not work!!!
  Replace by looping until the required condition is met.
sql-common/client.c:
  mysql_ssl_set() did not free old pointers before overwriting with new ones (happens when
  mysql_ssl_set() is called twice without calling mysql_close() in-between).
  
  This sometimes caused memory leaks in the slave depending on exact timing of
  master/slave shutdown.
  
  Fixed by freeing old pointers before installing new ones in mysql_ssl_set(), just like
  mysql_options() does.
2009-06-23 14:00:24 +02:00
Davi Arnaut
eac6619ff0 Merge from mysql-5.0-bugteam. 2009-06-10 11:05:07 -03:00
Davi Arnaut
a141a6375a Merge from mysql-5.0-bugteam. 2009-06-10 11:05:07 -03:00
Davi Arnaut
afacea4d60 Bug#41190: shared memory connections do not work in Vista, if server started from cmdline
Backport to MySQL 5.0/1 fix by Vladislav Vaintroub:

In Vista and later and also in when using terminal services, when
server is started from  command line, client cannot connect to it
via shared memory protocol.

This is a regression introduced when  Bug#24731 was fixed.  The
reason is that client is trying to attach to shared memory using
global kernel object  namespace (all kernel objects are prefixed
with Global\). However, server started from the command line in
Vista and later will create shared memory and events using current
session namespace. Thus, client is unable to find the server and
connection fails.

The fix for the client is to first try to find server using "local"
names  (omitting Global\  prefix) and only if server is not found,
trying global namespace.
2009-06-10 10:59:59 -03:00
Davi Arnaut
425790610d Bug#41190: shared memory connections do not work in Vista, if server started from cmdline
Backport to MySQL 5.0/1 fix by Vladislav Vaintroub:

In Vista and later and also in when using terminal services, when
server is started from  command line, client cannot connect to it
via shared memory protocol.

This is a regression introduced when  Bug#24731 was fixed.  The
reason is that client is trying to attach to shared memory using
global kernel object  namespace (all kernel objects are prefixed
with Global\). However, server started from the command line in
Vista and later will create shared memory and events using current
session namespace. Thus, client is unable to find the server and
connection fails.

The fix for the client is to first try to find server using "local"
names  (omitting Global\  prefix) and only if server is not found,
trying global namespace.
2009-06-10 10:59:59 -03:00
Staale Smedseng
aede9b7d13 Adding missing forward declaration for bug 43560 2009-05-20 19:34:37 +02:00
Staale Smedseng
6922ead265 Adding missing forward declaration for bug 43560 2009-05-20 19:34:37 +02:00
Staale Smedseng
059dba14b7 Recommit of bug 43560 after merge with mysql-5.1-bugteam 2009-05-20 16:17:47 +02:00
Staale Smedseng
57ba432293 Recommit of bug 43560 after merge with mysql-5.1-bugteam 2009-05-20 16:17:47 +02:00
Michael Widenius
e726e587ec Merged with mysql-5.1 tree.
client/mysqltest.cc:
  Manually merged
configure.in:
  Manually merged
mysql-test/r/variables.result:
  Manually merged
mysql-test/t/variables.test:
  Manually merged
mysys/my_pread.c:
  Manually merged
mysys/my_read.c:
  Manually merged
sql/mysqld.cc:
  Manually merged
storage/csv/ha_tina.h:
  Manually merged
storage/myisam/ha_myisam.cc:
  Manually merged
storage/myisam/mi_check.c:
  Manually merged
storage/myisam/mi_search.c:
  Manually merged
2009-04-25 13:05:32 +03:00
Ignacio Galarza
1aefa8029f auto-merge 2009-03-19 09:42:36 -04:00
Ignacio Galarza
8fd4c59ff6 auto-merge 2009-03-19 09:42:36 -04:00
Alexey Kopytov
f7cf8e57c1 Fix for bug #40552: Race condition around default_directories
in load_defaults() 

load_defaults(), my_search_option_files() and 
my_print_default_files()  utilized a global variable 
containing  a pointer to thread local memory. This could lead 
to race conditions when those functions were called with high 
concurrency. 

Fixed by changing the interface of the said functions to avoid 
the necessity for using a global variable.

Since we cannot change load_defaults() prototype for API
compatibility reasons, it was renamed my_load_defaults().
Now load_defaults() is a thread-unsafe wrapper around
a thread-safe version, my_load_defaults().


mysys/default.c:
  1. Added a thread-safe version of load_defaults(), changed
  load_defaults() with the old interface to be a thread-unsafe
  wrapper around the thread-safe version.
  2. Always use a private MEM_ROOT in my_print_default_files, 
  don't use a global variable.
sql-common/client.c:
  Use a thread-safe version of load_defaults().
2009-02-27 11:26:06 +02:00
Alexey Kopytov
752cbab9a4 Fix for bug #40552: Race condition around default_directories
in load_defaults() 

load_defaults(), my_search_option_files() and 
my_print_default_files()  utilized a global variable 
containing  a pointer to thread local memory. This could lead 
to race conditions when those functions were called with high 
concurrency. 

Fixed by changing the interface of the said functions to avoid 
the necessity for using a global variable.

Since we cannot change load_defaults() prototype for API
compatibility reasons, it was renamed my_load_defaults().
Now load_defaults() is a thread-unsafe wrapper around
a thread-safe version, my_load_defaults().
2009-02-27 11:26:06 +02:00
Ignacio Galarza
5b7347bda3 Bug#29125 Windows Server X64: so many compiler warnings
- 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
2009-02-13 11:41:47 -05:00
Ignacio Galarza
2d9421c3bb Bug#29125 Windows Server X64: so many compiler warnings
- 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
2009-02-13 11:41:47 -05:00
Ignacio Galarza
54fbbf9591 Bug#29125 Windows Server X64: so many compiler warnings
- 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
2009-02-10 17:47:54 -05:00
Ignacio Galarza
2b85c64d65 Bug#29125 Windows Server X64: so many compiler warnings
- 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
2009-02-10 17:47:54 -05:00
Sergei Golubchik
e2219ec965 wt_thd_lazy_init(), per-thread deadlock search depths and timeouts
mysys/array.c:
  lazy alloc in dynamic array
sql-common/client.c:
  for dynamic array, specify init_alloc==alloc_increment explicitly
sql/mysqld.cc:
  per-thread deadlock search depths and timeouts
sql/set_var.cc:
  per-thread deadlock search depths and timeouts
sql/sql_class.h:
  per-thread deadlock search depths and timeouts
2008-08-08 13:11:27 +02:00
unknown
18a01ce924 fixed warnings and compile errors from the fix for bug 26243 2008-03-29 09:52:16 +02:00
gkodinov/kgeorge@macbook.gmz
7cb4b7c19d fixed warnings and compile errors from the fix for bug 26243 2008-03-29 09:52:16 +02:00
unknown
f77686df0d Merge quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0
into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged


libmysql/libmysql.c:
  Auto merged
sql-common/client.c:
  Auto merged
tests/mysql_client_test.c:
  Manually merged.
2008-03-18 13:53:51 +03:00