Commit graph

21598 commits

Author SHA1 Message Date
anozdrin/alik@ibm.
e79410dad5 Fix typo. 2007-06-29 17:59:19 +04:00
anozdrin/alik@ibm.
bceff6f1d4 Folow up on the CS patch:
1. Fix ddl_i18n_koi8r, ddl_i18n_utf8: explicitly specify character-sets
directory for mysqldump;
2. Fix crash in mysqldump if collation is not found;
3. Use proper way to compare character set names.
2007-06-29 16:52:05 +04:00
anozdrin/alik@ibm.
9fae9ef66f Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
    has a non-ascii symbol
  - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
  - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
  - BUG#21249: Character set of SP-var can be ignored
  - BUG#25212: Character set of string constant is ignored (stored routines)
  - BUG#25221: Character set of string constant is ignored (triggers)

There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
   triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
   inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
   definition;

1. No query-definition-character set.

In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.

The context contains the following data:
  - client character set;
  - connection collation (character set and collation);
  - collation of the owner database;

The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).

2. Wrong mysqldump-output.

The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.

Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).

The solution is
  - to store definition queries in the original character set;
  - to change SHOW CREATE statement to output definition query in the
    binary character set (i.e. without any conversion);
  - introduce SHOW CREATE TRIGGER statement;
  - to dump special statements to switch the context to the original one
    before dumping and restore it afterwards.

Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.

3. INFORMATION_SCHEMA showed non-UTF8 strings

The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.

Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.

This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object.  Specialized SHOW CREATE statements should be
used for this.

The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).

Example:

  - original query:
    CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;

  - UTF8 query (for INFORMATION_SCHEMA):
    CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 21:34:54 +04:00
malff/marcsql@weblab.(none)
64cac0d6ad Merge weblab.(none):/home/marcsql/TREE/mysql-5.1-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge
2007-06-27 09:15:12 -06:00
malff/marcsql@weblab.(none)
083bd79bc6 Merge weblab.(none):/home/marcsql/TREE/mysql-5.1-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge
2007-06-25 11:02:17 -06:00
holyfoot/hf@hfmain.(none)
0d7168602d Merge bk@192.168.21.1:mysql-5.1-opt
into  mysql.com:/home/hf/work/27084/my51-27084
2007-06-25 14:28:30 +05:00
igor@olga.mysql.com
31bd1715db Merge olga.mysql.com:/home/igor/mysql-5.0-opt
into  olga.mysql.com:/home/igor/mysql-5.1-opt
2007-06-24 19:06:09 -07:00
gshchepa/uchum@gleb.loc
a1ebc8590c Merge gleb.loc:/home/uchum/work/bk/5.1
into  gleb.loc:/home/uchum/work/bk/5.1-opt
2007-06-25 03:40:30 +05:00
igor@olga.mysql.com
da41606087 Merge olga.mysql.com:/home/igor/mysql-5.0-opt
into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug25602
2007-06-24 10:50:24 -07:00
gshchepa/uchum@gleb.loc
684d0ced77 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-06-24 12:58:45 +05:00
igor@olga.mysql.com
59b9077ce4 Fixed bug . A query with DISTINCT in the select list to which
the loose scan optimization for grouping queries was applied returned 
a wrong result set when the query was used with the SQL_BIG_RESULT
option.

The SQL_BIG_RESULT option forces to use sorting algorithm for grouping
queries instead of employing a suitable index. The current loose scan
optimization is applied only for one table queries when the suitable
index is covering. It does not make sense to use sort algorithm in this
case. However the create_sort_index function does not take into account
the possible choice of the loose scan to implement the DISTINCT operator
which makes sorting unnecessary. Moreover the current implementation of
the loose scan for queries with distinct assumes that sorting will
never happen. Thus in this case create_sort_index should not call
the function filesort.
2007-06-23 23:33:55 -07:00
gshchepa/uchum@gleb.loc
2cd4abebfb Merge gleb.loc:/home/uchum/work/bk/5.0-opt
into  gleb.loc:/home/uchum/work/bk/5.1-opt
2007-06-24 03:35:27 +05:00
gshchepa/uchum@gleb.loc
e5798d0466 Merge gleb.loc:/home/uchum/work/bk/5.0-opt-29095
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-06-24 01:22:25 +05:00
gshchepa/uchum@gleb.loc
fbbb30a622 Fixed bug .
INSERT into table from SELECT from the same table
with ORDER BY and LIMIT was inserting other data
than sole SELECT ... ORDER BY ... LIMIT returns.

One part of the patch for bug  improperly pushed
LIMIT to temporary table in the presence of the ORDER BY
clause.
That part has been removed.
2007-06-24 01:20:14 +05:00
guilhem@gbichot3.local
fa1276e4a1 Fix for BUG#29318 "Statements prepared with PREPARE and with one
parameter don't use query cache"
Thanks to the fix of BUG#26842, statements prepared with SQL PREPARE
and having parameters can now use the query cache.
2007-06-23 19:16:51 +02:00
kostja@bodhi.(none)
8b8b44151c Fix broken automatic dependency tracking of Automake in sql/:
The embedded library is still broken, but there the situation
with dependencies is even more broken.
2007-06-22 19:58:27 +04:00
thek@adventure.(none)
2da5b6268a Merge adventure.(none):/home/thek/Development/cpp/bug28846/my51-bug28846
into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
2007-06-22 15:39:34 +02:00
thek@adventure.(none)
0edfc7394d Bug Use of undocumented Prepared Statements crashes server
- Manual merge patch.
2007-06-22 15:38:23 +02:00
thek@adventure.(none)
3d7bc219f1 Merge adventure.(none):/home/thek/Development/cpp/bug28846/my50-bug28846
into  adventure.(none):/home/thek/Development/cpp/bug28846/my51-bug28846
2007-06-22 15:23:51 +02:00
thek@adventure.(none)
3e7c1b1cb1 Bug#28846 Use of undocumented Prepared Statements crashes server
ALTER VIEW is currently not supported as a prepared statement
and should be disabled as such as they otherwise could cause server crashes.

ALTER VIEW is currently not supported when called from stored
procedures or functions for related reasons and should also be disabled.

This patch disables these DDL statements and adjusts the appropriate test
cases accordingly.

Additional tests has been added to reflect on the fact that we do support
CREATE/ALTER/DROP TABLE for Prepared Statements (PS), Stored Procedures (SP)
and PS within SP.
2007-06-22 11:55:48 +02:00
igor@olga.mysql.com
802dcc7a45 Merge olga.mysql.com:/home/igor/mysql-5.0-opt
into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29104
2007-06-21 15:25:23 -07:00
tsmith@maint1.mysql.com
28242f775c Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.1-rpl
into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/51
2007-06-21 22:10:40 +02:00
tsmith@maint1.mysql.com
8ee2c2b04e Merge maint1.mysql.com:/data/localhome/tsmith/bk/maint/50
into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/51
2007-06-21 20:55:37 +02:00
tsmith@maint1.mysql.com
b8881ebfd4 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-rpl
into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/50
2007-06-21 20:09:04 +02:00
tsmith@maint1.mysql.com
3ae37d30de Merge maint1.mysql.com:/data/localhome/tsmith/bk/51
into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/51
2007-06-21 18:58:31 +02:00
tsmith@maint1.mysql.com
f1e600a78e Merge maint1.mysql.com:/data/localhome/tsmith/bk/50
into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/50
2007-06-21 18:28:52 +02:00
lars/lthalmann@dl145k.mysql.com
5c667b6fa5 Merge mysql.com:/nfsdisk1/lars/bk/mysql-5.1
into  mysql.com:/nfsdisk1/lars/bk/mysql-5.1-new-rpl
2007-06-21 17:13:02 +02:00
lars/lthalmann@dl145j.mysql.com
d0e786b8e9 Merge mysql.com:/nfsdisk1/lars/bk/mysql-5.0
into  mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl
2007-06-21 17:10:35 +02:00
lars/lthalmann@dl145k.mysql.com
1fb2aa8205 Merge mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl
into  mysql.com:/nfsdisk1/lars/bk/mysql-5.1-new-rpl
2007-06-21 17:04:33 +02:00
msvensson@pilot.(none)
8e65f66378 Merge pilot.(none):/data/msvensson/mysql/mysql-5.0-maint
into  pilot.(none):/data/msvensson/mysql/mysql-5.1-new-maint
2007-06-21 16:58:22 +02:00
holyfoot/hf@hfmain.(none)
56be687ce8 Merge bk@192.168.21.1:mysql-5.1-opt
into  mysql.com:/home/hf/work/28839/my51-28839
2007-06-21 12:07:52 +05:00
holyfoot/hf@hfmain.(none)
8a6b7f7cca Merge bk@192.168.21.1:mysql-5.0-opt
into  mysql.com:/home/hf/work/28839/my50-28839
2007-06-21 12:04:13 +05:00
tnurnberg@sin.intern.azundris.com
3c1be00069 Bug#24924: shared-memory-base-name that is too long causes buffer overflow
long shared-memory-base-names could overflow a static internal buffer
and thus crash mysqld and various clients.  change both to dynamic
buffers, show everything but overflowing those buffers still works.

The test case for this would pretty much amount to
mysqld --shared-memory-base-name=HeyMrBaseNameXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --shared-memory=1 &
mysqladmin --no-defaults --shared-memory-base-name=HeyMrBaseNameXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX shutdown

Unfortunately, we can't just use an .opt file for the
server. The .opt file is used at start-up, before any
include in the actual test can tell mysqltest to skip
this one on non-Windows. As a result, such a test would
break on unices.

Fixing mysql-test-run.pl to export full path for master
and slave would enable us to start a server from within
the test which is ugly and, what's more, doesn't work as
the server blocks (mysqltest offers no fire-and-forget
fork-and-exec), and mysqladmin never gets run.

Making the test rpl_windows_shm or some such so we can
is beyond ugly. As is introducing another file-name based
special case (run "win*.test" only when on Windows). As is
(yuck) coding half the test into mtr (as in, having it
hand out a customized environment conductive to the shm-
thing on Win only).

Situation is exacerbated by the fact that .sh is not
necessary run as expected on Win.

In short, it's just not worth it. No test-case until we
have a new-and-improved test framework.
2007-06-21 04:30:10 +02:00
gshchepa/uchum@gleb.loc
1b5d893122 Fixed bug .
Occasionally mysqlbinlog --hexdump failed with error:
  ERROR 1064 (42000) at line ...: You have an error in your
  SQL syntax; check the manual that corresponds to your MySQL
  server version for the right syntax to use near
  'Query thread_id=... exec_time=... error_code=...

When the length of hexadecimal dump of binlog header was
divisible by 16, commentary sign '#' after header was lost.
The Log_event::print_header function has been modified to always
finish hexadecimal binlog header with "\n# ".
2007-06-21 02:11:28 +05:00
igor@olga.mysql.com
c6cc50960b Fixed bug : assertion abort for grouping queries using views.
The abort happened when a query contained a conjunctive predicate
of the form 'view column = constant' in the WHERE condition and 
the grouping list also contained a reference to a view column yet
a different one.

Removed the failing assertion as invalid in a general case.

Also fixed a bug that prevented applying some optimization for grouping
queries using views. If the WHERE condition of such a query contains
a conjunctive condition of the form 'view column = constant' and
this view column is used in the grouping list then grouping by this
column can be eliminated. The bug blocked performing this elimination.
2007-06-20 12:43:14 -07:00
mats@kindahl-laptop.dnsalias.net
6f9f5b01bf Merge kindahl-laptop.dnsalias.net:/home/bkroot/mysql-5.0-rpl
into  kindahl-laptop.dnsalias.net:/home/bk/b29030-mysql-5.0-rpl
2007-06-20 20:33:36 +02:00
mats@kindahl-laptop.dnsalias.net
2f74826394 BUG#29030 (DROP USER command that errors still gets written to binary log
and replicated):

A DROP USER statement with a non-existing user was correctly written to
the binary log (there might be users that were removed, but not all),
but the error code was not set, which caused the slave to stop with an
error.

The error reporting code was moved to before the statement was logged
to ensure that the error information for the thread was correctly set
up. This works since my_error() will set the fields net.last_errno and
net.last_error for the thread that is reporting the error, and this
will then be picked up when the Query_log_event is created and written
to the binary log.
2007-06-20 14:24:31 +02:00
aelkin/elkin@dsl-hkibras1-ff5dc300-70.dhcp.inet.fi
9391d42165 Bug slave sql fails to read from iocache when slave got stopped at pos==4
forgotten merge with 5.0. There can be some bugs waiting for this fix in 5.0 like Bug@29232
2007-06-20 13:21:16 +03:00
holyfoot/hf@hfmain.(none)
72fd5c0388 Merge mysql.com:/home/hf/work/28839/my50-28839
into  mysql.com:/home/hf/work/28839/my51-28839
2007-06-20 14:16:55 +05:00
holyfoot/hf@mysql.com/hfmain.(none)
3b08919f6a Bug Errors in strict mode silently stop SQL thread if --slave-skip-errors exists.
slave_sql thread calls thd->clear_error() to force error to be ignored,
though this method didn't clear thd->killed state, what causes
slave_sql thread to stop.

clear thd->killed state if we ignore an error
2007-06-20 14:05:49 +05:00
gshchepa/uchum@gleb.loc
5d056de5ff Merge gleb.loc:/home/uchum/work/bk/5.0-opt-28898
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-06-20 13:06:24 +05:00
gshchepa/uchum@gleb.loc
2379f9778d Fixed bug .
For a join query with GROUP BY and/or ORDER BY and a view reference
in the FROM list the metadata erroneously showed empty table aliases
and database names for the view columns.
2007-06-20 12:25:07 +05:00
tomas@whalegate.ndb.mysql.com
3bd4019fad Merge whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-ndb
into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-rpl
2007-06-20 06:26:23 +02:00
dkatz@damien-katzs-computer.local
a197a9aa8a Merge damien-katzs-computer.local:/Users/dkatz/mysql50
into  damien-katzs-computer.local:/Users/dkatz/mysql51
2007-06-19 18:18:59 -04:00
dkatz@damien-katzs-computer.local
bd80d7e465 Merge damien-katzs-computer.local:/Users/dkatz/mysql50
into  damien-katzs-computer.local:/Users/dkatz/50_win
2007-06-19 18:03:47 -04:00
tomas@whalegate.ndb.mysql.com
7fa3b3cfa2 Merge whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-ndb
2007-06-19 15:28:26 +02:00
tomas@whalegate.ndb.mysql.com
895f2f15af Bug Large IN list crashes mysqld with cluster and condition pushdown 2007-06-19 13:56:02 +02:00
gkodinov/kgeorge@magare.gmz
e5acb070aa Merge bk-internal:/home/bk/mysql-5.1-opt
into  magare.gmz:/home/kgeorge/mysql/autopush/B26418-5.1-opt
2007-06-19 14:30:03 +03:00
gkodinov/kgeorge@magare.gmz
bef15b279b Bug : Slave out of sync after
CREATE/DROP TEMPORARY TABLE + ROLLBACK on master

The transaction ability of the storage engines of
the tables on the replication master and the replication
slave must generally be the same.
When the storage engine type of the slave is 
non-transactional then transactions on the master that 
mix update of transactional and non-transactional tables
should be avoided because they will cause inconsistency of
the data between the master's transactional table and the
slave's non-transactional table.

The effect described by this bug is actually expected.
A detailed test case is added (to be merged later to
the updated rpl_ddl.test), as there was no coverage 
by the existing tests. 
Some code cleanup is also added by this change.
2007-06-19 14:27:53 +03:00
kostja@bodhi.(none)
68632318dc Manual merge. 2007-06-19 15:02:08 +04:00