1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-01 03:26:54 +03:00
Commit Graph

355 Commits

Author SHA1 Message Date
7c5d18e227 Bug #20772273 : MYSQLIMPORT --USE-THREADS DOESN'T USE
MULTIPLE THREADS

Description:- The utility "mysqlimport" does not use
multiple threads for the execution with option
"--use-threads". "mysqlimport" while importing multiple
files and multiple tables, uses a single thread even if the
number of threads are specified with "--use-threads" option.

Analysis:- This utility uses ifdef HAVE_LIBPTHREAD to check
for libpthread library and if defined uses libpthread
library for mutlithreaing. Since HAVE_LIBPTHREAD is not
defined anywhere in the source, "--use-threads" option is
silently ignored.

Fix:- "-DTHREADS" is set to the COMPILE_FLAGS  which will
enable pthreads. HAVE_LIBPTHREAD macro is removed.
2015-06-30 10:27:12 +05:30
8d87015412 Bug #16996656: UNIQUE OPTION PREFIXES NOT DEPRECATED IN 5.5+
Backported the deprecation warnings from WL#6978 to 5.5
2013-06-26 12:19:02 +03:00
459bee9cad Bug #15930494 MYSQLDUMP TEST SOMETIMES FAILS DUE TO MIXING STDOUT AND
STDERR

      Fix: Added a destination file to mysqldump.
2012-12-07 18:26:02 +05:30
f1e9b7219c Bug#14463669 FAILURE TO CORRECTLY PARSE ROUTINES IN
MYSQLDUMP OUTPUT

Problem: mysqldump when used with option --routines, dumps
         all the routines of the specified database into
         output. The statements in this output are written
         in such a way that they are version safe using C
         style version commenting (of the format
         /*!<version num> <sql statement>*/). If a semicolon
         is present right before closing of the comment in
         dump output, it results in a syntax error while
         importing.


Solution: Version comments for dumped routines are
          specifically to protect the ones older than 5.0.
          When the import is done on 5.0 or later versions,
          entire create statement gets executed as all the
          check conditions at the beginning of the comments
          are cleared. Since the trade off is between the
          performance of newer versions which are more in
          use and protection of very old versions which are
          no longer supported, it is proposed that these
          comments be removed altogether to maintain
          stability of the versions supported.
2012-11-19 21:41:35 +05:30
e6f0b97b50 Bug #11753490: 44939: sql dumps containing broad views fail when
executing

The problem is that mysql lacks information about the objects a view
depends on so it can't dump views and tables in the proper order.
Thus it needs to create "stand-in" myisam tables for each view while 
dumping the tables that it later drops and replaces with the actual view
view definition.
But since views can have much more columns than an actual table creating
these stand-in tables may be problematic.

There's no way to portably find out how many columns an mysiam table
can have. It's a complicated formula depending on internal server constants.
Thus we can't have a reliable error check without repeating the logic and 
the formula inside mysqldump.

1. Changed the type of the columns of the stand-in tables mysqldump
makes to satisfy view dependencies from the original type to smallint 
to save on row space.

2. Added a warning on the mysqldump's standard error for a possible 
problems replaying the dump file if the columns of a view exceed 1000.

3. Added a test case.
2012-07-04 17:48:58 +03:00
066dc9a281 Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY
CAUSES RESTORE PROBLEM

Merging the fix from mysql-5.1 to mysql-5.5
2012-05-07 16:51:26 +05:30
41cdad9868 Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY
CAUSES RESTORE PROBLEM
Problem Statement:
------------------
mysqldump is not having the dump stmts for general_log and slow_log
tables. That is because of the fix for Bug#26121. Hence, after 
dropping the mysql database, and applying the dump by enabling the 
logging, "'general_log' table not found" errors are logged into the 
server log file.

Analysis:
---------
As part of the fix for Bug#26121, we skipped the dumping of tables 
for general_log and slow_log, because the data dump of those tables 
are taking LOCKS, which is not allowed for log tables.

Fix:
----
We came up with an approach that instead of taking both meta data 
and data dump information for those tables, take only the meta data 
dump which doesn't need LOCKS.
As part of fixing the issue we came up with below algorithm.
Design before fix:
1) mysql database is having tables like db, event,... general_log,
   ... slow_log...
2) Skip general_log and slow_log while preparing the tables list
3) Take the TL_READ lock on tables which are present in the table 
   list and do 'show create table'.
4) Release the lock.

Design with the fix:
1) mysql database is having tables like db, event,... general_log,
   ... slow_log...
2) Skip general_log and slow_log while preparing the tables list
3) Explicitly call the 'show create table' for general_log and 
   slow_log
3) Take the TL_READ lock on tables which are present in the table 
   list and do 'show create table'.
4) Release the lock.

While taking the meta data dump for general_log and slow_log the 
"CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". 
This is because we skipped "DROP TABLE" for those tables, 
"DROP TABLE" fails for these tables if logging is enabled. 
Customer is applying the dump by enabling logging so, if the dump 
has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" 
stmts for those tables.
  
After the fix we could observe "Table 'mysql.general_log' 
doesn't exist" errors initially that is because in the customer 
scenario they are dropping the mysql database by enabling the 
logging, Hence, those errors are expected. Once we apply the 
dump which is taken before the "drop database mysql", the errors 
will not be there.
2012-05-04 18:33:34 +05:30
e2e91b7b7c Merge of fix for bug#11760384 from mysql-5.1. 2012-01-10 16:10:48 +05:30
7faf69dd82 BUG#11760384 - 52792: mysqldump in XML mode does not dump
routines.

mysqldump in xml mode did not dump routines, events or
triggers.

This patch fixes this issue by fixing the if conditions
that disallowed the dump of above mentioned objects in
xml mode, and added the required code to enable dump
in xml format.
2012-01-10 13:33:45 +05:30
0a8824e9c3 Bug#12809202 61854: MYSQLDUMP --SINGLE-TRANSACTION
--FLUSH-LOG BREAKS CONSISTENCY

Post-fix for some failing tests.
2011-12-24 15:08:59 +05:30
a4343d56ed Bug#12809202 61854: MYSQLDUMP --SINGLE-TRANSACTION
--FLUSH-LOG BREAKS CONSISTENCY

The transaction started by mysqldump gets committed
implicitly when flush-log is specified along with
single-transaction option, and hence can break
consistency.

This is because, COM_REFRESH is executed in order
to flush logs and starting from 5.5 this command
performs an implicit commit.

Fixed by making sure that COM_REFRESH is executed
before the transaction has started and not after it.

Note : This patch triggers following behavioral
       changes in mysqldump :

1) After this patch we no longer flush logs before
   dumping each database if --single-transaction
   option is given like it was done before (in the
   absence of --lock-all-tables and --master-data
   options).

2) Also, after this patch, we start acquiring
   FTWRL before flushing logs in cases when only
   --single-transaction and --flush-logs are given.
   It becomes safe to use mysqldump with these two
   options and without --master-data parameter for
   backups.
2011-12-23 23:05:00 +05:30
5a3586b1c3 Fixed the test cleanup code post-merge 2011-03-17 14:07:18 +02:00
da70b67a41 Minor fix in mysqldump test. 2011-03-17 16:28:16 +05:30
18d2e55c51 Merge from mysql-5.5.10-release 2011-03-16 15:11:20 +01:00
000a390e81 Merge of fix for bug#11766310 from mysql-5.1 -> mysql-5.5. 2011-02-21 12:42:27 +05:30
a8e6f7c67b Bug#11766310 : 59398: MYSQLDUMP 5.1 CAN'T HANDLE A DASH
("-") IN DATABASE NAMES IN ALTER DATABASE.

mysqldump did not quote database name in 'ALTER DATABASE'
statements in its output. This can further cause a failure
while loading if database name contains a hyphen '-'.

This happened as, while printing the 'ALTER DATABASE'
statements, the database name was not quoted.

Fixed by quoting the database name.
2011-02-21 12:37:24 +05:30
77c0f33ee2 Fix for BUG#59894
"set optimizer_switch to e or d causes invalid memory writes/valgrind warnings":
due to prefix support, the argument "e" was overwritten with its full value
"engine_condition_pushdown", which caused a buffer overrun.
This was wrong usage of find_type(); other wrong usages are fixed here too.
Please start reading with the comment of typelib.c.
2011-02-11 15:00:09 +01:00
95e07a6fb7 Bug#13618 : mysqldump --xml omits comment on table field
When mysqldump tries to dump information in xml format,
the result does not contain field level comments.

In order to retrieve various informations for a field/column,
mysqldump currently uses 'show fields from <tab>' statement.
The attributes returned by the statement lacks the information
regarding field comments.

Fixed by changing the query to one that probes I_S to retrieve
required field informations, including the field comment.
2011-01-14 19:50:34 +05:30
43a2f80e16 Merging fix of Bug#13618 from mysql-5.1. 2011-01-14 20:11:00 +05:30
ad43230e3b Manual merge of mysql-5.1-bugteam to mysql-trunk-merge.
Conflicts:

Text conflict in mysql-test/r/grant.result
Text conflict in mysql-test/t/grant.test
Text conflict in mysys/mf_loadpath.c
Text conflict in sql/slave.cc
Text conflict in sql/sql_priv.h
2010-05-09 02:03:35 +04:00
c4021e2d43 Bug #53088: mysqldump with -T & --default-character-set set
truncates text/blob to 766 chars

mysqldump and SELECT ... INTO OUTFILE truncated long BLOB/TEXT
values to size of 766 bytes (MAX_FIELD_WIDTH or 255 * 3 + 1).

The select_export::send_data method has been modified to
reallocate a conversion buffer for long field data.
2010-05-07 00:41:37 +04:00
7c10a8981c Patch for WL#3736: Extended Table, Column and Index Comments.
The task is to 
  (a) add a comment on indexes and 
  (b) increase the maximum length of column, table and the new index comments.

The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
2010-02-20 13:07:32 +03:00
f02525be83 Backport of WL #2934: Make/find library for doing float/double
to string conversions and vice versa" 
Initial import of the dtoa.c code and custom wrappers around it 
to allow its usage from the server code. 
 
Conversion of FLOAT/DOUBLE values to DECIMAL ones or strings 
and vice versa has been significantly reworked. As the new 
algoritms are more precise than the older ones, results of such 
conversions may not always match those obtained from older 
server versions. This in turn may break compatibility for some 
applications. 
 
This patch also fixes the following bugs: 
- bug #12860 "Difference in zero padding of exponent between 
Unix and Windows" 
- bug #21497 "DOUBLE truncated to unusable value" 
- bug #26788 "mysqld (debug) aborts when inserting specific 
numbers into char fields" 
- bug #24541 "Data truncated..." on decimal type columns 
without any good reason"
2009-12-22 19:23:13 +03:00
8c95f3c53b Manual merge from mysql-next-mr. 2009-11-02 14:10:04 +03:00
ac7ba1bcaa Merge from mysql-next-mr. 2009-10-28 10:55:44 +03:00
c6aeab8cfe Automerge from mysql-next-mr. 2009-10-27 12:59:09 +03:00
dbe504ec7a Bug#35427 INFORMATION_SCHEMA.TABLES.TABLE_CATALOG is NULL, should be "def"
backport to betony
2009-10-23 16:02:20 +05:00
58e2fde011 manual merge: mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-merge
Conflicts
=========

Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.

NOTE
====
 mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
 - "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"

 This is the first cset (merge/...) committed after pulling 
 from mysql-next-mr.
2009-10-22 23:30:28 +01:00
43bf01e337 Bug #21099 MySQL 5.0.22 silently creates MyISAM tables even though
InnoDB specified.
            
NO_ENGINE_SUBSTITUTION added to TRADITIONAL sql mode to prevent
silent conversions from InnoDB to MyISAM in that sql mode.

A number of test case results files updated to reflect this change.
Test added to sql_mode.test that checks that TRADITIONAL really 
includes NO_ENGINE_SUBSTITUION.
2009-10-09 16:52:02 +02:00
83177656d9 A backport of a patch for Bug#35297.
Original revision in mysql-6.0-codebase is:

revno: 2617.31.14
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Sat 2009-03-28 11:42:55 +0300
message:
  Bug#35297 SHOW CREATE EVENT does not show the DEFINER:
  update test result after a merge from now.
2009-10-08 00:57:03 +04:00
1b3300d5e9 Backport BUG#34227 Replication permission error message is misleading
According to Jon's comment, add (at least one of) to the error message.
2009-10-02 16:50:05 +08:00
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
e642140b18 Bug# 30946: mysqldump silently ignores --default-character-set
when used with --tab

1) New syntax: added CHARACTER SET clause to the
  SELECT ... INTO OUTFILE (to complement the same clause in
  LOAD DATA INFILE).
  mysqldump is updated to use this in --tab mode.

2) ESCAPED BY/ENCLOSED BY field parameters are documented as
   accepting CHAR argument, however SELECT .. INTO OUTFILE
   silently ignored rests of multisymbol arguments.
   For the symmetrical behavior with LOAD DATA INFILE the
   server has been modified to fail with the same error:

     ERROR 42000: Field separator argument is not what is
                  expected; check the manual

3) Current LOAD DATA INFILE recognizes field/line separators
   "as is" without converting from client charset to data
   file charset. So, it is supposed, that input file of
   LOAD DATA INFILE consists of data in one charset and
   separators in other charset. For the compatibility with
   that [buggy] behaviour SELECT INTO OUTFILE implementation
   has been saved "as is" too, but the new warning message
   has been added:

     Non-ASCII separator arguments are not fully supported

   This message warns on field/line separators that contain
   non-ASCII symbols.
2009-07-31 22:14:52 +05:00
bd0a44fba2 Merge in bug fixes for client tools 2009-07-14 10:08:38 -07:00
f9025ea331 Merge bug fixes 2009-07-13 12:11:16 -07:00
7eeff66cba Bug#34861: mysqldump with --tab gives weird output for triggers.
mysqldump --tab still dumped triggers to stdout rather than to
individual tables.

We now append triggers to the .sql file for the corresponding
table.

--events and --routines correspond to a database rather than a
table and will still go to stdout with --tab unless redirected
with --result-file (-r).
2009-05-27 15:16:21 +02:00
16aeb5ad3d Table identifiers and file names were not quoted and escaped correctly by
mysqlimport. (Bug #28071)
2009-05-19 15:26:57 -07:00
caba34a1b4 The output of mysqldump --tab for views included a DROP TABLE statement
without the IF EXISTS qualifier even though no temporary table is created
as for all-in-one dumps including views. (Bug #37377)
2009-05-18 12:52:51 -07:00
883ddef98a mysqlimport was not always compiled correctly to allow thread support,
required for the --use-threads option. (Bug #32991)
2009-05-12 10:45:40 -07:00
e3fa685917 mysqldump would not dump the INFORMATION_SCHEMA even when it was explicitly
requested. (Bug #33762)
2009-05-12 10:38:14 -07:00
d2f2edbb92 Merge 5.0-bugteam to 5.1-bugteam. 2009-04-21 15:25:04 +05:00
904498295f BUG#36966 - mysqldump.test fails in pushbuild
mysqldump.test is designed to run with concurrent inserts
disabled. It is disabling concurrent inserts at the very
beginning of the test case, and re-enables them at the
bottom of the test. But for some reason (likely incorrect
merge) we enable concurrent inserts in the middle of the test.

The problem is fixed by enabling concurrent inserts only
at the bottom of the test case.
2009-04-21 14:01:13 +05:00
8744675faf Merge fix for bug 42635, which is no change for 5.1 except addition of
test and (slightly different than 5.0) results.
2009-03-12 11:39:40 -04:00
6b72857803 Merge from bugfix tree. 2009-03-10 12:53:43 -04:00
0d9589a433 Bug#42635: mysqldump includes views that were excluded using the \
--ignore-table option

mysqldump would correctly omit temporary tables for views, but would
incorrectly still emit all CREATE VIEW statements.

Backport a fix from 5.1, where we capture the names we want to emit
views for in one pass (the placeholder tables) and in the pass where
we actually emit the views, we don't emit a view if it wasn't in that
list.
2009-03-09 16:58:47 -04:00
c51b672c33 5.0-bugteam->5.1-bugteam merge 2009-02-25 16:18:24 +04:00
8587e4f989 Bug#40345 MySQLDump prefixes view name with database name when view references other db
print compact view name if the view belongs to the current database
2009-02-25 15:44:50 +04:00
1d85ad238b manual merge 2009-02-19 18:22:28 +01:00
f218f9f278 Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.

In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
2009-02-19 17:33:28 +01:00
449bfbd7fa Merge 5.0 -> 5.1
+ fix wrong resultfile have_outfile.require
2009-02-03 14:45:17 +01:00