if mysql.proc does not exist.

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

The problem is that unimplemented WIN32 version of pthread_kill
is returning ESRCH no matter the arguments, causing calls to
mysqld_list_processes to set the procinfo to dead because
pthread_kill returns non zero. The dead procinfo would show
up on a second invocation of show processlist.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

Each time the server reloads privileges containing table grants, the 
system will allocate too much memory than needed because of badly
chosen growth prediction in the underlying dynamic arrays.

This patch introduces a new signature to the hash container initializer
which enables a much more pessimistic approach in favour for more
efficient memory useage.

This patch was supplied by Google Inc.

into  buzz.(none):/home/davi/mysql-5.1-runtime

The problem was in a test case for Bug33507:
  - when the number of active connections reaches the limit,
    the server accepts only root connections. That's achieved by
    accepting a connection, negotiating with the client and
    checking user credentials. If it is not SUPER, the connection
    is dropped.
  - when the server accepts connection, it increases the counter;
  - when the server drops connection, it decreases the counter;
  - the race was in between of decreasing the counter and accepting
    new connection:
    - max_user_connections = 2;
    - 2 oridinary user connections accepted;
    - extra user connection is establishing;
    - server checked user credentials, and sent 'Too many connections'
      error;
    - the client receives the error and establishes extra SUPER user
      connection;
    - the server however didn't decrease the counter (the extra
      user connection still is "alive" in the server) -- so, the new
      SUPER-user connection, will be dropped, because it exceeds
      (max_user_connections + 1).

The fix is to implement "safe connect", which makes several attempts
to connect and use it in the test script.

The problem was that 'connect' command didn't set mysql_errno
variable, thus the script was unable to determine whether connection
was opened or not.

The fix is to set this variable.

Test cases will be added in the scope of Bug33507
into connect.test file.

The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.

The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.

in some case.

ER_CON_COUNT_ERROR is defined with SQL state 08004. However, this SQL state is not always
returned.

This error can be thrown in two cases:

  1. when an ordinary user (a user w/o SUPER privilege) is connecting,
    and the number of active user connections is equal or greater than
    max_connections.

  2. when a user is connecting and the number of active user connections is
    already (max_connections + 1) -- that means that no more connections will
    be accepted regardless of the user credentials.

In the 1-st case, SQL state is correct.

The bug happens in the 2-nd case -- on UNIX the client gets 00000 SQL state, which is
absolutely wrong (00000 means "not error SQL state); on Windows
the client accidentally gets HY000 (which means "unknown SQL state).

The cause of the problem is that the server rejects extra connection
prior to read a packet with client capabilities. Thus, the server
does not know if the client supports SQL states or not (if the client
supports 4.1 protocol or not). So, the server supposes the worst and
does not send SQL state at all.

The difference in behavior on UNIX and Windows occurs because on Windows
CLI_MYSQL_REAL_CONNECT() invokes create_shared_memory(), which returns
an error (in default configuration, where shared memory is not configured).
Then, the client does not reset this error, so when the connection is
rejected, SQL state is HY000 (from the error from create_shared_memory()).

The bug appeared after test case for Bug#33507 -- before that, this behavior
just had not been tested.

The fix is to 1) reset the error after create_shared_memory();
2) set SQL state to 'unknown error' if it was not received from
the server.

A separate test case is not required, since the behavior is already
tested in connect.test.

Note for doc-team: the manual should be updated to say that under
some circumstances, 'Too many connections' has HY000 SQL state.

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

The problem is that since MyISAM's concurrent_insert is on by
default some concurrent SELECT statements might not see changes
made by INSERT statements in other connections, even if the
INSERT statement has returned.

The solution is to disable concurrent_insert so that INSERT
statements returns after the data is actually visible to other
statements.

into  quad.:/mnt/raid/alik/MySQL/devel/bug-35074/5.1-rt-bug35074

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

  
Disable test case for bug 29948, which is causing sporadically
failures in other tests inside mysql_client_test.

The problem was that number of threads was used to calculate
max_used_connections.

The fix is to use number of active connections.

than max_connections -- which results in user lockout.

The problem was that the variable thread_count that contains
the number of active threads was interpreted as a number of
active connections.

The fix is to introduce a new counter for active connections.

bug12713.

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

  
In cases when TRUNCATE was executed by invoking mysql_delete() rather
than by table recreation (for example, when TRUNCATE was issued on
InnoDB table with is referenced by foreign key) triggers were invoked.
In debug builds this also led to crash because of an assertion, which
assumes that some preliminary actions take place before trigger 
invocation, which doesn't happen in case of TRUNCATE.

The fix is not to execute triggers in mysql_delete() when this
function is used by TRUNCATE.

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-4.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  riffraff.(none):/data0/martin/bug34367/my51-bug34367-pushee