Commit graph

13235 commits

Author SHA1 Message Date
pgalbraith/patg@govinda.patg.net
9da072cb5b Merge pgalbraith@bk-internal.mysql.com:/home/bk/mysql-5.0-engines
into  govinda.patg.net:/home/patg/mysql-build/mysql-5.1-engines-merge
2006-08-11 14:06:23 -07:00
pgalbraith/patg@govinda.patg.net
b2ce951b81 Merge pgalbraith@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  govinda.patg.net:/home/patg/mysql-build/mysql-5.1-engines-merge
2006-08-10 15:31:44 -07:00
patg@govinda.patg.net
4371749996 Merge pgalbraith@bk-internal.mysql.com:/home/bk/mysql-5.1
into  govinda.patg.net:/home/patg/mysql-build/mysql-5.1-engines-merge
2006-08-10 14:28:39 -07:00
kroki/tomash@moonlight.intranet
b341356abd Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-runtine-merge
2006-08-10 16:16:16 +04:00
kroki/tomash@moonlight.intranet
aca2c3761a Merge moonlight.intranet:/home/tomash/src/mysql_ab/tmp_merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
2006-08-10 16:11:55 +04:00
andrey@example.com
eba9109225 after merge update 2006-08-10 11:52:34 +02:00
andrey@lmy004.
9a325ac786 Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  lmy004.:/work/mysql-5.1-runtime
2006-08-09 17:19:39 +02:00
andrey@lmy004.
76ff7fb78f Fix for bug#20701 BINARY keyword should be forbidden in stored routines
create function func() returns char(10) binary ...
is no more possible. This will be reenabled when 
bug 2676 "DECLARE can't have COLLATE clause in stored procedure"
is fixed.

Fix after 2nd review
2006-08-09 17:07:59 +02:00
kroki/tomash@moonlight.intranet
e79876362e Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-rt-merge
2006-08-09 16:42:21 +04:00
kroki/tomash@moonlight.intranet
5c272816ca Merge moonlight.intranet:/home/tomash/src/mysql_ab/tmp_merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
2006-08-09 13:37:20 +04:00
patg@govinda.patg.net
21f7f34776 BUG #21524 "'ps' test fails in --ps-protocol test AMD64 bit"
(this is not a fix to the bug, but simply to disable the test in 
order to push a 5.0 to 5.1 merge)

This merge contains:

Push by holyfoot@production.mysql.com on Tue Jul 25 13:41:40 2006:

bk clone -l -r'holyfoot/hf@mysql.com/deer.(none)|ChangeSet|20060725085017|41021' mysql-5.0 tmp_merge
2006-08-08 14:32:39 -07:00
patg@govinda.patg.net
8d1e5a5bb1 Merge govinda.patg.net:/home/patg/mysql-build/mysql-5.0-holyfoot
into  govinda.patg.net:/home/patg/mysql-build/mysql-5.1-5.0-merge2

Push by holyfoot@production.mysql.com on Tue Jul 25 13:41:40 2006:

bk clone -l -r'holyfoot/hf@mysql.com/deer.(none)|ChangeSet|20060725085017|41021' mysql-5.0 tmp_merge
2006-08-08 09:01:32 -07:00
svoj@may.pils.ru
b5cd11cf0e After merge fix. 2006-08-07 19:35:02 +05:00
andrey@lmy004.
9c59cfe4d7 Fix for bug#21416 SP: Recursion level higher than zero needed for non-recursive call
The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;

Actually there is no recursive call but the limit is checked.

Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.
2006-08-04 12:50:49 +02:00
petr/cps@owlet.
af461de728 Merge pchardin@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  mysql.com:/home/cps/mysql/devel/5.1-curs-bug
2006-08-04 14:48:51 +04:00
tsmith@maint1.mysql.com
a4eb61b88c Merge bk-internal:/home/bk/mysql-5.1-new-maint
into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c
2006-08-04 00:40:30 +02:00
tsmith@maint1.mysql.com
d6c4c3bad2 Manual merge resolve, part 6 of 6+ 2006-08-03 19:43:52 +02:00
msvensson@neptunus.(none)
34d48ce10a Use "--source" command instead of "source", makes mysql-test-run.pl dtecte this as test case that need binlog format row. 2006-08-03 19:35:00 +02:00
tsmith@maint1.mysql.com
e0b9910728 Merge maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-a
into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c
2006-08-03 19:28:20 +02:00
petr/cps@mysql.com/owlet.
be2ce2614b Fix Bug #18559 "log tables cannot change engine, and
gets deadlocked when dropping w/ log on"

Log tables rely on concurrent insert machinery to add data.
This means that log tables are always opened and locked by
special (artificial) logger threads. Because of this, the thread
which tries to drop a log table starts to wait for the table
to be unlocked. Which will happen only if the log table is disabled.
Alike situation happens if one tries to alter a log table.
However in addition to the problem above, alter table calls
check_if_locking_is_allowed() routine for the engine. The
routine does not allow alter for the log tables. So, alter
doesn't start waiting forever for logs to be disabled, but 
returns with an error.
Another problem is that not all engines could be used for
the log tables. That's because they need concurrent insert.

In this patch we:
(1) Explicitly disallow to drop/alter a log table if it
    is currently used by the logger.
(2) Update MyISAM to support log tables
(3) Allow to drop log tables/alter log tables if log is
    disabled
At the same time we (4) Disallow to alter log tables to
unsupported engine (after this patch CSV and MyISAM are 
alowed)
Recommit with review fixes.
2006-08-03 21:28:15 +04:00
tsmith@maint1.mysql.com
b9ac526884 5.0 -> 5.1 manual merge, part 5 of 5 (or more?) 2006-08-03 19:27:00 +02:00
petr/cps@mysql.com/owlet.
7aec120549 Fix Bug #20139 Infinite loop after "FLUSH" and "LOCK tabX, general_log"
Due to incorrect handling of FLUSH TABLES, log tables were marked for flush,
but not reopened. Later we started to wait for the log table to be closed
(disabled) after the flush. And as nobody disabled logs in concurrent treads,
the command lasted forever.
After internal consultations it was decided to skip logs during FLUSH TABLES.
The reasoning is that logging is done in the "log device", whatever it is
which is always active and controlled by FLUSH LOGS. So, to flush logs
one should use FLUSH LOGS, and not FLUSH TABLES.
2006-08-03 17:23:37 +04:00
tsmith@maint1.mysql.com
8e0cc34af4 Merge maint1.mysql.com:/data/localhome/tsmith/bk/mrg50-c
into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c
2006-08-03 10:41:14 +02:00
tsmith@maint1.mysql.com
06060fd602 Merge maint1.mysql.com:/data/localhome/tsmith/bk/mrg50-b
into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-b
2006-08-03 10:18:04 +02:00
tsmith@maint1.mysql.com
242ed711d2 5.0 -> 5.1 manual merge, part 1 of 3 (or more?) 2006-08-03 10:04:25 +02:00
ingo/istruewing@chilla.local
ff32920719 Bug#18775 - Temporary table from alter table visible to other threads
New test cases. Names with umlauts don't compare well on Windows.
2006-08-03 08:12:56 +02:00
ingo/istruewing@chilla.local
c20030ef26 Merge istruewing@bk-internal.mysql.com:/home/bk/mysql-5.1-engines
into  chilla.local:/home/mydev/mysql-5.1-bug18775
2006-08-02 18:10:51 +02:00
ingo/istruewing@chilla.local
8e4c36ad4a Bug#18775 - Temporary table from alter table visible to other threads
Continued implementation of WL#1324 (table name to filename encoding)

The intermediate (not temporary) files of the new table
during ALTER TABLE was visible for SHOW TABLES. These
intermediate files are copies of the original table with
the changes done by ALTER TABLE. After all the data is
copied over from the original table, these files are renamed 
to the original tables file names. So they are not temporary 
files. They persist after ALTER TABLE, but just with another 
name.

In 5.0 the intermediate files are invisible for SHOW TABLES
because all file names beginning with "#sql" were suppressed.

This failed since 5.1.6 because even temporary table names were
converted when making file names from them. The prefix became
converted to "@0023sql". Converting the prefix during SHOW TABLES
would suppress the listing of user tables that start with "#sql".

The solution of the problem is to continue the implementation of
the table name to file name conversion feature. One requirement
is to suppress the conversion for temporary table names.

This change is straightforward for real temporary tables as there
is a function that creates temporary file names.

But the generated path names are located in TMPDIR and have no
relation to the internal table name. This cannot be used for
ALTER TABLE. Its intermediate files need to be in the same
directory as the old table files. And it is necessary to be
able to deduce the same path from the same table name repeatedly.

Consequently the intermediate table files must be handled like normal
tables. Their internal names shall start with tmp_file_prefix
(#sql) and they shall not be converted like normal table names.

I added a flags parameter to all relevant functions that are
called from ALTER TABLE. It is used to suppress the conversion
for the intermediate table files.

The outcome is that the suppression of #sql in SHOW TABLES
works again. It does not suppress user tables as these are
converted to @0023sql on file level.

This patch does also fix ALTER TABLE ... RENAME, which could not 
rename a table with non-ASCII characters in its name.

It does also fix the problem that a user could create a table like
`#sql-xxxx-yyyy`, where xxxx is mysqld's pid and yyyy is the thread
ID of some other thread, which prevented this thread from running 
ALTER TABLE.

Some of the above problems are mentioned in Bug 1405, which can
be closed with this patch.

This patch does also contain some minor fixes for other forgotten
conversions. Still known problems are reported as bugs 21370,
21373, and 21387.
2006-08-02 17:57:06 +02:00
evgen@moonbone.local
83896aa8f6 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  moonbone.local:/work/tmp_merge-5.0-opt-mysql
2006-08-02 18:11:59 +04:00
msvensson@neptunus.(none)
554b1f019b Merge neptunus.(none):/home/msvensson/mysql/mysql-5.1
into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint
2006-08-02 15:45:03 +02:00
msvensson@neptunus.(none)
e6348e0277 Disable crash_commit_before waiting for a "crash()" function that won't generate a core. 2006-08-02 15:41:59 +02:00
evgen@moonbone.local
90f23a251a Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1
into  moonbone.local:/work/tmp_merge-5.0-opt-mysql
2006-08-02 16:48:17 +04:00
evgen@moonbone.local
7f0a080660 Merge moonbone.local:/work/tmp_merge-4.1-opt-mysql
into  moonbone.local:/work/tmp_merge-5.0-opt-mysql
2006-08-02 16:46:55 +04:00
evgen@moonbone.local
67c85a170a Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0
into  moonbone.local:/work/tmp_merge-5.0-opt-mysql
2006-08-02 16:44:56 +04:00
evgen@moonbone.local
cac5ad03b9 Merge moonbone.local:/work/tmp_merge-4.1
into  moonbone.local:/work/tmp_merge-4.1-opt-mysql
2006-08-02 16:40:32 +04:00
svoj@may.pils.ru
6c6f435b03 BUG#14770 - LOAD DATA INFILE doesn't respect default values for
columns
Fixed confusing warning.

Quoting INSERT section of the manual:
----
Inserting NULL into a column that has been declared NOT NULL. For
multiple-row INSERT statements or INSERT INTO ... SELECT statements, the
column is set to the implicit default value for the column data type. This
is 0 for numeric types, the empty string ('') for string types, and the
"zero" value for date and time types. INSERT INTO ... SELECT statements are
handled the same way as multiple-row inserts because the server does not
examine the result set from the SELECT to see whether it returns a single
row. (For a single-row INSERT, no warning occurs when NULL is inserted into
a NOT NULL column. Instead, the statement fails with an error.)
----
This is also true for LOAD DATA INFILE. For INSERT user can specify
DEFAULT keyword as a value to set column default. There is no similiar
feature available for LOAD DATA INFILE.
2006-08-02 17:15:50 +05:00
evgen@moonbone.local
40a1fbdffb Merge moonbone.local:/work/tmp_merge-4.1
into  moonbone.local:/work/tmp_merge-4.1-opt-mysql
2006-08-02 16:10:52 +04:00
holyfoot/hf@mysql.com/deer.(none)
2119067eee Merge bk@192.168.21.1:mysql-4.1
into  mysql.com:/home/hf/work/mysql-4.1.20317
2006-08-02 16:57:46 +05:00
tsmith@maint1.mysql.com
438b94e204 .del-sp.test.orig:
Delete: mysql-test/t/sp.test.orig
2006-08-02 02:21:36 +02:00
evgen@sunlight.local
d6cf536d93 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.1
into  sunlight.local:/local_work/tmp_merge-5.1-opt-mysql
2006-08-02 02:19:46 +04:00
evgen@sunlight.local
d4f92cbb5c Merge sunlight.local:/local_work/tmp_merge-5.0-opt-mysql
into  sunlight.local:/local_work/tmp_merge-5.1-opt-mysql
2006-08-01 20:52:21 +04:00
evgen@sunlight.local
a8405f650d func_str.result:
After merge fix
2006-08-01 18:55:44 +04:00
gkodinov/kgeorge@rakia.(none)
8cf5a4c04e Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  rakia.(none):/home/kgeorge/mysql/autopush/B20103-5.0-opt
2006-08-01 11:17:14 +03:00
gkodinov/kgeorge@macbook.gmz
7b5e4ed026 Bug #20103: Escaping with backslash does not work
- make the client to respect the server-side 
   no_backslash_escapes option and disable the 
   special meaning of backslash also at client side.
2006-08-01 11:05:54 +03:00
msvensson@neptunus.(none)
39130d15eb Merge neptunus.(none):/home/msvensson/mysql/my51-m-bug19535
into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint
2006-08-01 09:33:00 +02:00
evgen@sunlight.local
dda7a95c59 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.1-opt
into  sunlight.local:/local_work/tmp_merge-5.1-opt-mysql
2006-08-01 09:24:19 +04:00
evgen@sunlight.local
799ecc9f2a After merge fix 2006-08-01 08:49:43 +04:00
gkodinov/kgeorge@rakia.(none)
63d198af1c Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  rakia.(none):/home/kgeorge/mysql/autopush/B11551-5.0-opt
2006-08-01 06:11:11 +03:00
evgen@sunlight.local
6806776eed Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  sunlight.local:/local_work/tmp_merge-5.0-opt-mysql
2006-08-01 06:42:33 +04:00
evgen@sunlight.local
1007b441df Merge sunlight.local:/local_work/tmp_merge-5.0-opt-mysql
into  sunlight.local:/local_work/tmp_merge-5.1-opt-mysql
2006-07-31 23:49:52 +04:00