GitLab

Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"

Test cases for bugs 4968, 19733, 6895 will be added in 5.0.

Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).

The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table were not
re-execution friendly: during their operation they used to modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc 
for drop_it.remove() and similar patterns to find evidence.

The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement. 

To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.

The problem of crashing bug 22060 stemmed from the fact that the above 
metnioned functions were not only modifying HA_CREATE_INFO structure in 
LEX, but also were changing it to point to areas in volatile memory of 
the execution memory root.
 
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).

mysqldump / SHOW CREATE TABLE will show the NEXT available value for
the PK, rather than the *first* one that was available (that named in
the original CREATE TABLE ... AUTO_INCREMENT = ... statement).

This should produce correct and robust behaviour for the obvious use
cases -- when no data were inserted, then we'll produce a statement
featuring the same value the original CREATE TABLE had; if we dump
with values, INSERTing the values on the target machine should set the
correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT =
... to do that). Lastly, just the CREATE statement (with no data) for
a table that saw inserts would still result in a table that new values
could safely be inserted to).

There seems to be no robust way however to see whether the next_ID
field is > 1 because it was set to something else with CREATE TABLE
... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column
in  the table (but no initial value was set with AUTO_INCREMENT = ...)
and then one or more rows were INSERTed, counting up next_ID. This
means that in both cases, we'll generate an AUTO_INCREMENT =
... clause in SHOW CREATE TABLE / mysqldump.  As we also show info on,
say, charsets even if the user did not explicitly give that info in
their own CREATE TABLE, this shouldn't be an issue.

As per above, the next_ID will be affected by any INSERTs that have
taken place, though.  This /should/ result in correct and robust
behaviour, but it may look non-intuitive to some users if they CREATE
TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have
SHOW CREATE TABLE give them a different value (say, CREATE TABLE
... AUTO_INCREMENT = 1006), so the docs should possibly feature a
caveat to that effect.

It's not very intuitive the way it works now (with the fix), but it's
*correct*.  We're not storing the original value anyway, if we wanted
that, we'd have to change on-disk representation?

If we do dump/load cycles with empty DBs, nothing will change.  This
changeset includes an additional test case that proves that tables
with rows will create the same next_ID for AUTO_INCREMENT = ... across
dump/restore cycles.

Confirmed by support as likely solution for client's problem.

during shutdown. (Bug #11796)

After SHOW TABLE STATUS last_insert_id wasn't cleaned, and next select
erroneously rewrites WHERE condition and returs a row;
5.0 isn't affected because of different SHOW TABLE STATUS handling.

last_insert_id cleanup added to mysqld_extend_show_tables().

  "CHARACTER SET", "COLLATE", and "DEFAULT" are always
  printed(excepting MODE_MYSQL323 and MODE_MYSQL40)
  "AUTO_INCREMENT", "ON UPDATE CURRENT_TIMESTAMP" are printed only 
  if NO_FIELD_OPTIONS is not set.

After merge fix.

   This fix is cancellation of ChangeSet
   1.2329 05/07/12 08:35:30 reggie@linux.site +8 -0
   Bug 7142  Show Fields from fails using Borland's dbExpress interface
   The reason is we can't fix bug#7142 without
   breaking of existing applications/APIs that worked fine with earlier 4.1
   bug 7142 is fixed in 5.0

The problem here is that columns that have an especially long type 
such as an enum type with many options would be longer than 40 chars
but the type column returned from show columns always was defined
as varchar(40).

This is fixed in 5.0 using info schema.

  - Change output from SHOW CREATE TABLE to use USING instead of TYPE

Changed type of "Sub_part" column in SHOW KEYS from TINYINT to SMALLINT (as MAX_KEY_LENGTH=1024)
(this is the final cset with proper tests)

"After Monty's review" changes to the fix for BUG#8325 "Deadlock in replication thread stops replication":
s/sleep/safe_sleep (thread safe); sleep 0/1/2/3/4/5/5/5 (get slave less late);
no message on error log (deadlock is too common sometimes), a global counter
instead (SHOW STATUS LIKE 'slave_retried_transactions').
Plus a fix for libmysql/Makefile.shared

sql_show.cc:
  changed strdup to thd->memdup per Serg's advice

This is a modifiction of my previous patch after receiving feedback. This is a better way to fix the problem.  With this patch, data directory and index directory will use only forward slashes (/) when on Windows.

mysqldump.c:
  Removed fixPaths routine.  Was improper fix for bug #6660
sql_show.cc:
  Changed append_directory to convert backslashes to foward slashes when on Windows.

Call file->extra() with HA_STATUS_CONST in mysqld_show_keys.
The fix will not be merged into 4.1/5.0 because they don't have this problem already.

SHOW KEYS FROM t1 now displays number of characters in Sub_part,
not number of bytes, to be compatible with SHOW CREATE TABLE.

This patch collects all previous patches into one.

The main problem was due to that there is are two variables -
dflt_key_cache and sql_key_cache with have more or less duplicate
function. The reson for the bug was that the default value in the key
cache hash was set to dflt_key_cache, then sql_key_cache was set to a
new key cache object, and then dflt_key_cache was set to sql_key_cache
which was different from the dflt_key_cache_var. After sending SIGHUP,
the server was using the original default value for the key cache hash,
which was different from the actual key cache object used for the
default key cache.

tables that support multiple index types. (Bug #7235)

tables requires privileges for them if some table or column level grants
present" (with after-review fixes).

We should set SELECT_ACL for implicitly opened tables in 
my_tz_check_n_skip_implicit_tables() to be able to bypass privilege
checking in check_grant(). Also we should exclude those tables from
privilege checking in multi-update.

A test doesn't seem to be possible.

Added protocol::flush() for easier embedded-server code
Increase block allocation variables a bit as they where a bit too small for MySQL 4.1
Added option --silent to client_test

"uint *errors" is now a non-optional parameter in String:copy()
and copy_and_convert().

Simple optimzations and cleanups
Removed compiler warnings and fixed portability issues
Added client functions 'mysql_embedded()' to allow client to check if we are using embedded server
Fixes for purify

Some bigger code changes was necessary becasue of the multi-table-update and the new HANDLER code

  ctype_recode does not hang anymore. Small fix after Marko's change.

column types TIMESTAMP is NOT NULL by default, so in order to have 
TIMESTAMP column holding NULL valaues you have to specify NULL as
one of its attributes (this needed for backward compatibility).

Main changes:
Replaced TABLE::timestamp_default_now/on_update_now members with
TABLE::timestamp_auto_set_type flag which is used everywhere
for determining if we should auto-set value of TIMESTAMP field 
during this operation or not. We are also use Field_timestamp::set_time()
instead of handler::update_timestamp() in handlers.

* Changed the implementation of ndbcluster_find_files to be more efficient, using only one mutex lock
* Moved ha_find_files to end of mysql_find_files so that it can be passed the list that we are interested to find. 

sql_show.cc:
  Made change suggested by Serge. REmoved else in mysql_find_files so symlink files fall through to the wildcard check

  Logging to logging@openlogging.org accepted
sql_show.cc, type_enum.test, type_enum.result:
  Bug #5628 German characters in field-defs will be '?' with some table definitions

sql_show.cc:
  Added wild card check to symdir block in mysql_find_files

Changed WL#1424 to use the function ha_find_files. This is a simpler implementation and all handler specific code is hidden in the appropriate handler.

  Bug#4417: SHOW CREATE TABLE and SHOW COLUMNS now return consistent results when "SET NAMES BINARY", i.e. everything is sent in UTF8: column names, enum values, default values.

New handler::index_flags() definition to make it easy to check the full used key and a specific key part.
Added key part to optimize_range() to fix problems when using fields in key parts.