| bk commit - mysqldoc@docsrva tree (paul:1.3282) |
|
 |
Index ‹ mysql
|
- Previous
- 1
- bk commit into 4.1 tree (bar:1.2350) BUG#5439Below is the list of changes that have just been committed into a local
4.1 repository of bar. When bar does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.2350 05/08/08 19:52:30 email***@***.com +4 -0
Bug#5439 : mysql_server_init() crashes if ShiftJIS path is passed
(important for Adobe).
mf_pack.c, mf_dirname.c, charset.c, my_sys.h:
- adding fs_character_set() function on Windows
- ignoring fake slashes which are just multibyte
parts in several functions in /mysys
Verified by Shu to work on WinXP and Win2k.
Test is not possible, or very hard to do.
mysys/mf_pack.c
1.21 05/08/08 19:51:18 email***@***.com +12 -0
d
mysys/mf_dirname.c
1.11 05/08/08 19:51:16 email***@***.com +32 -1
d
mysys/charset.c
1.137 05/08/08 19:51:11 email***@***.com +26 -0
d
include/my_sys.h
1.139 05/08/08 19:49:54 email***@***.com +5 -0
Bug#5439 : mysql_server_init() crashes if ShiftJIS path is passed
(important for Adobe)
- adding fs_character_set() function on Windows
- ignoring fake slashes which are just multibyte
parts in several functions in /mysys
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: bar
# Host: bar.intranet.mysql.r18.ru
# Root: /usr/home/bar/mysql-4.1.b5439
--- 1.138/include/my_sys.h 2005-07-20 15:27:52 +05:00
+++ 1.139/include/my_sys.h 2005-08-08 19:49:54 +05:00
@@ -788,6 +788,11 @@
extern void add_compiled_collation(CHARSET_INFO *cs);
extern ulong escape_string_for_mysql(CHARSET_INFO *charset_info, char *to,
const char *from, ulong length);
+#ifdef __WIN__
+#define BACKSLASH_MBTAIL
+/* File system character set */
+extern CHARSET_INFO *fs_character_set(void);
+#endif
#ifdef __WIN__
extern my_bool have_tcpip; /* Is set if tcpip is used */
--- 1.136/mysys/charset.c 2005-07-25 21:32:40 +05:00
+++ 1.137/mysys/charset.c 2005-08-08 19:51:11 +05:00
@@ -637,3 +637,29 @@
*to= 0;
return (ulong) (to - to_start);
}
+
+
+#ifdef BACKSLASH_MBTAIL
+static CHARSET_INFO *fs_cset_cache= NULL;
+
+CHARSET_INFO *fs_character_set()
+{
+ if (!fs_cset_cache)
+ {
+ char buf[10]= "cp";
+ GetLocaleInfo(LOCALE_SYSTEM_DEFAULT, LOCALE_IDEFAULTANSICODEPAGE,
+ buf+2, sizeof(buf)-3);
+ /*
+ We cannot call get_charset_by_name here
+ because fs_character_set() is executed before
+ LOCK_THD_charset mutex initialization, which
+ is used inside get_charset_by_name.
+ As we're now interested in cp932 only,
+ let's just detect it using strcmp().
+ */
+ fs_cset_cache= !strcmp(buf, "cp932") ?
+ &my_charset_cp932_japanese_ci : &my_charset_bin;
+ }
+ return fs_cset_cache;
+}
+#endif
--- 1.10/mysys/mf_dirname.c 2003-10-07 16:12:07 +05:00
+++ 1.11/mysys/mf_dirname.c 2005-08-08 19:51:16 +05:00
@@ -22,6 +22,9 @@
uint dirname_length(const char *name)
{
register my_string pos,gpos;
+#ifdef BASKSLASH_MBTAIL
+ CHARSET_INFO *fs= fs_character_set();
+#endif
#ifdef FN_DEVCHAR
if ((pos=(char*)strrchr(name,FN_DEVCHAR)) == 0)
#endif
@@ -29,12 +32,22 @@
gpos= pos++;
for ( ; *pos ; pos++) /* Find last FN_LIBCHAR */
+ {
+#ifdef BASKSLASH_MBTAIL
+ uint l;
+ if (use_mb(fs) && (l= my_ismbchar(fs, pos, pos + 3)))
+ {
+ pos+= l - 1;
+ continue;
+ }
+#endif
if (*pos == FN_LIBCHAR || *pos == '/'
#ifdef FN_C_AFTER_DIR
|| *pos == FN_C_AFTER_DIR || *pos == FN_C_AFTER_DIR_2
#endif
)
gpos=pos;
+ }
return ((uint) (uint) (gpos+1-(char*) name));
}
@@ -85,6 +98,9 @@
char *convert_dirname(char *to, const char *from, const char *from_end)
{
char *to_org=to;
+#ifdef BACKSLASH_MBTAIL
+ CHARSET_INFO *fs= fs_character_set();
+#endif
/* We use -2 here, becasue we need place for the last FN_LIBCHAR */
if (!from_end || (from_end - from) > FN_REFLEN-2)
@@ -103,7 +119,22 @@
*to++= FN_C_AFTER_DIR;
#endif
else
- *to++= *from;
+ {
+#ifdef BACKSLASH_MBTAIL
+ uint l;
+ if (use_mb(fs) && (l= my_ismbchar(fs, from, from + 3)))
+ {
+ memmove(to, from, l);
+ to+= l;
+ from+= l - 1;
+ to_org= to; /* Don't look inside mbchar */
+ }
+ else
+#endif
+ {
+ *to++= *from;
+ }
+ }
}
*to=0;
}
--- 1.20/mysys/mf_pack.c 2005-05-21 02:53:34 +05:00
+++ 1.21/mysys/mf_pack.c 2005-08-08 19:51:18 +05:00
@@ -124,6 +124,9 @@
reg4 my_string start;
char parent[5], /* for "FN_PARENTDIR" */
buff[FN_REFLEN+1],*end_parentdir;
+#ifdef BACKSLASH_MBTAIL
+ CHARSET_INFO *fs= fs_character_set();
+#endif
DBUG_ENTER("cleanup_dirname");
DBUG_PRINT("enter",("from: '%s'",from));
@@ -141,6 +144,15 @@
length=(uint) (strmov(parent+1,FN_PARENTDIR)-parent);
for (pos=start ; (*pos= *from_ptr++) != 0 ; pos++)
{
+#ifdef BACKSLASH_MBTAIL
+ uint l;
+ if (use_mb(fs) && (l= my_ismbchar(fs, from_ptr - 1, from_ptr + 2)))
+ {
+ for (l-- ; l ; *++pos= *from_ptr++, l--);
+ start= pos + 1; /* Don't look inside multi-byte char */
+ continue;
+ }
+#endif
if (*pos == '/')
*pos = FN_LIBCHAR;
if (*pos == FN_LIBCHAR)
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 1
- bk commit into 5.0 tree (jimw:1.1913) BUG#7293Below is the list of changes that have just been committed into a local
5.0 repository of jimw. When jimw does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.1913 05/04/28 14:46:54 email***@***.com +2 -0
Add regression test for calling SOUNDEX() within stored procedure.
The bug appears to have already been fixed. (Bug #7293)
mysql-test/t/sp.test
1.115 05/04/28 14:46:51 email***@***.com +17 -0
Add regression test for bug 7293
mysql-test/r/sp.result
1.120 05/04/28 14:46:51 email***@***.com +16 -0
Add results for new test
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jimw
# Host: rama.(none)
# Root: /home/jimw/my/mysql-5.0-7293
--- 1.119/mysql-test/r/sp.result 2005-04-22 03:53:42 -07:00
+++ 1.120/mysql-test/r/sp.result 2005-04-28 14:46:51 -07:00
@@ -3041,4 +3041,20 @@
delete from t1|
drop procedure bug9004_1|
drop procedure bug9004_2|
+drop procedure if exists bug7293|
+insert into t1 values ('secret', 0)|
+create procedure bug7293(p1 varchar(100))
+begin
+if exists (select id from t1 where soundex(p1)=soundex(id)) then
+select 'yes';
+end if;
+end;|
+call bug7293('secret')|
+yes
+yes
+call bug7293 ('secrete')|
+yes
+yes
+drop procedure bug7293|
+delete from t1|
drop table t1,t2;
--- 1.114/mysql-test/t/sp.test 2005-04-22 03:53:42 -07:00
+++ 1.115/mysql-test/t/sp.test 2005-04-28 14:46:51 -07:00
@@ -3723,6 +3723,23 @@
drop procedure bug9004_1|
drop procedure bug9004_2|
+#
+# BUG#7293: Stored procedure crash with soundex
+#
+--disable_warnings
+drop procedure if exists bug7293|
+--enable_warnings
+insert into t1 values ('secret', 0)|
+create procedure bug7293(p1 varchar(100))
+begin
+ if exists (select id from t1 where soundex(p1)=soundex(id)) then
+ select 'yes';
+ end if;
+end;|
+call bug7293('secret')|
+call bug7293 ('secrete')|
+drop procedure bug7293|
+delete from t1|
#
# BUG#NNNN: New bug synopsis
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 1
- bk commit into 5.0 tree (svoj:1.2004)Below is the list of changes that have just been committed into a local
5.0 repository of svoj. When svoj does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.2004 05/10/01 12:12:39 email***@***.com +2 -0
Merge email***@***.com:/bk/mysql-5.0-cnet
into mysql.com:/home/svoj/devel/mysql/CNET/merge/mysql-5.0
libmysqld/Makefile.am
1.64 05/10/01 12:12:34 email***@***.com +0 -0
Auto merged
BitKeeper/etc/ignore
1.211 05/10/01 12:12:27 email***@***.com +1 -1
auto-union
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: svoj
# Host: svoj-laptop.mysql.com
# Root: /home/svoj/devel/mysql/CNET/merge/mysql-5.0/RESYNC
--- 1.63/libmysqld/Makefile.am 2005-09-28 14:50:27 +05:00
+++ 1.64/libmysqld/Makefile.am 2005-10-01 12:12:34 +05:00
@@ -65,7 +65,7 @@
spatial.cc gstream.cc sql_help.cc tztime.cc sql_cursor.cc \
sp_head.cc sp_pcontext.cc sp.cc sp_cache.cc sp_rcontext.cc \
parse_file.cc sql_view.cc sql_trigger.cc my_decimal.cc \
- ha_blackhole.cc
+ ha_blackhole.cc sql_plugin.cc
libmysqld_int_a_SOURCES= $(libmysqld_sources) $(libmysqlsources) $(sqlsources) $(sqlexamplessources)
libmysqld_a_SOURCES=
--- 1.210/BitKeeper/etc/ignore 2005-09-23 01:46:39 +05:00
+++ 1.211/BitKeeper/etc/ignore 2005-10-01 12:12:27 +05:00
@@ -495,6 +495,7 @@
libmysqld/sql_map.cc
libmysqld/sql_olap.cc
libmysqld/sql_parse.cc
+libmysqld/sql_plugin.cc
libmysqld/sql_prepare.cc
libmysqld/sql_rename.cc
libmysqld/sql_repl.cc
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 1
- Connector/J commit: r4596 - in branches/branch_3_1/connector-j: . src/com/mysql/jdbc src/com/mysql/jdbc/log src/testsuite/regressionModified:
branches/branch_3_1/connector-j/CHANGES
branches/branch_3_1/connector-j/src/com/mysql/jdbc/ConnectionProperties.java
branches/branch_3_1/connector-j/src/com/mysql/jdbc/MysqlIO.java
branches/branch_3_1/connector-j/src/com/mysql/jdbc/ServerPreparedStatement.java
branches/branch_3_1/connector-j/src/com/mysql/jdbc/log/StandardLogger.java
branches/branch_3_1/connector-j/src/testsuite/regression/ConnectionRegressionTest.java
Log:
Fixed BUG#13048 - maxQuerySizeToLog is not respected. Added logging of
bound values for execute() phase of server-side prepared statements
when profileSQL=true as well.
Modified: branches/branch_3_1/connector-j/CHANGES
===================================================================
--- branches/branch_3_1/connector-j/CHANGES 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/CHANGES 2005-11-22 21:12:36 UTC (rev 4596)
@@ -75,6 +75,10 @@
arguments to PreparedStatements. Reverts to legacy behavior by
setting the JDBC configuration property "autoClosePStmtStreams"
to "true" (also included in the 3-0-Compat configuration "bundle").
+
+ - Fixed BUG#13048 - maxQuerySizeToLog is not respected. Added logging of
+ bound values for execute() phase of server-side prepared statements
+ when profileSQL=true as well.
10-07-05 - Version 3.1.11
Modified: branches/branch_3_1/connector-j/src/com/mysql/jdbc/ConnectionProperties.java
===================================================================
--- branches/branch_3_1/connector-j/src/com/mysql/jdbc/ConnectionProperties.java 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/src/com/mysql/jdbc/ConnectionProperties.java 2005-11-22 21:12:36 UTC (rev 4596)
@@ -543,8 +543,11 @@
private static final ArrayList PROPERTY_LIST = new ArrayList();
- private static final String STANDARD_LOGGER_NAME = StandardLogger.class
- .getName();
+ //
+ // Yes, this looks goofy, but we're trying to avoid intern()ing here
+ //
+ private static final String STANDARD_LOGGER_NAME = new String(StandardLogger.class
+ .getName().getBytes());
protected static final String ZERO_DATETIME_BEHAVIOR_CONVERT_TO_NULL = "convertToNull";
Modified: branches/branch_3_1/connector-j/src/com/mysql/jdbc/MysqlIO.java
===================================================================
--- branches/branch_3_1/connector-j/src/com/mysql/jdbc/MysqlIO.java 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/src/com/mysql/jdbc/MysqlIO.java 2005-11-22 21:12:36 UTC (rev 4596)
@@ -1692,8 +1692,8 @@
int extractPosition = oldPacketPosition;
- if (oldPacketPosition > MAX_QUERY_SIZE_TO_LOG) {
- extractPosition = MAX_QUERY_SIZE_TO_LOG;
+ if (oldPacketPosition > this.connection.getMaxQuerySizeToLog()) {
+ extractPosition = this.connection.getMaxQuerySizeToLog() + 5;
truncated = true;
}
Modified: branches/branch_3_1/connector-j/src/com/mysql/jdbc/ServerPreparedStatement.java
===================================================================
--- branches/branch_3_1/connector-j/src/com/mysql/jdbc/ServerPreparedStatement.java 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/src/com/mysql/jdbc/ServerPreparedStatement.java 2005-11-22 21:12:36 UTC (rev 4596)
@@ -1135,7 +1135,7 @@
this.connection.getId(), this.statementId, -1, System
.currentTimeMillis(), (int) (System
.currentTimeMillis() - begin), null,
- new Throwable(), null));
+ new Throwable(), truncateQueryToLog(asSql(true))));
}
com.mysql.jdbc.ResultSet rs = mysql.readAllResults(this,
@@ -1324,7 +1324,7 @@
this.connection.getId(), this.statementId, -1,
System.currentTimeMillis(), (int) (System
.currentTimeMillis() - begin), null,
- new Throwable(), sql));
+ new Throwable(), truncateQueryToLog(sql)));
}
if (this.parameterCount > 0) {
@@ -1382,6 +1382,23 @@
}
}
+ private String truncateQueryToLog(String sql) {
+ String query = null;
+
+ if (sql.length() > this.connection.getMaxQuerySizeToLog()) {
+ StringBuffer queryBuf = new StringBuffer(
+ this.connection.getMaxQuerySizeToLog() + 12);
+ queryBuf.append(sql.substring(0, this.connection.getMaxQuerySizeToLog()));
+ queryBuf.append(Messages.getString("MysqlIO.25"));
+
+ query = queryBuf.toString();
+ } else {
+ query = sql;
+ }
+
+ return query;
+ }
+
private void serverResetStatement() throws SQLException {
synchronized (this.connection.getMutex()) {
Modified: branches/branch_3_1/connector-j/src/com/mysql/jdbc/log/StandardLogger.java
===================================================================
--- branches/branch_3_1/connector-j/src/com/mysql/jdbc/log/StandardLogger.java 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/src/com/mysql/jdbc/log/StandardLogger.java 2005-11-22 21:12:36 UTC (rev 4596)
@@ -295,12 +295,12 @@
.findCallingClassAndMethod(locationException));
msgBuf.append(" ");
}
+
+ if (msg != null) {
+ msgBuf.append(String.valueOf(msg));
+ }
}
-
- if (msg != null) {
- msgBuf.append(String.valueOf(msg));
- }
-
+
if (exception != null) {
msgBuf.append("\n");
msgBuf.append("\n");
Modified: branches/branch_3_1/connector-j/src/testsuite/regression/ConnectionRegressionTest.java
===================================================================
--- branches/branch_3_1/connector-j/src/testsuite/regression/ConnectionRegressionTest.java 2005-11-22 19:53:43 UTC (rev 4595)
+++ branches/branch_3_1/connector-j/src/testsuite/regression/ConnectionRegressionTest.java 2005-11-22 21:12:36 UTC (rev 4596)
@@ -24,6 +24,9 @@
*/
package testsuite.regression;
+import java.io.ByteArrayOutputStream;
+import java.io.PrintStream;
+import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
@@ -1246,6 +1249,64 @@
}
/**
+ * Tests fix for BUG#13048 - maxQuerySizeToLog is
+ * not respected.
+ *
+ * @throws Exception if the test fails
+ */
+ public void testBug13048() throws Exception {
+
+ Connection profileConn = null;
+ PrintStream oldErr = System.err;
+
+ try {
+ ByteArrayOutputStream bOut = new ByteArrayOutputStream();
+ System.setErr(new PrintStream(bOut));
+
+ Properties props = new Properties();
+ props.setProperty("profileSQL", "true");
+ props.setProperty("maxQuerySizeToLog" ,"2");
+ props.setProperty("logger", "com.mysql.jdbc.log.StandardLogger");
+
+ profileConn = getConnectionWithProps(props);
+
+ StringBuffer queryBuf = new StringBuffer("SELECT '");
+
+ for (int i = 0; i < 500; i++) {
+ queryBuf.append("a");
+ }
+
+ queryBuf.append("'");
+
+ this.rs = profileConn.createStatement().executeQuery(queryBuf.toString());
+ this.rs.close();
+
+ String logString = new String(bOut.toString("ISO8859-1"));
+ assertTrue(logString.indexOf("... (truncated)") != -1);
+
+ bOut = new ByteArrayOutputStream();
+ System.setErr(new PrintStream(bOut));
+
+ this.rs = profileConn.prepareStatement(queryBuf.toString()).executeQuery();
+ logString = new String(bOut.toString("ISO8859-1"));
+
+ assertTrue(logString.indexOf("... (truncated)") != -1);
+ } finally {
+ System.setErr(oldErr);
+
+ if (profileConn != null) {
+ profileConn.close();
+ }
+
+ if (this.rs != null) {
+ ResultSet toClose = this.rs;
+ this.rs = null;
+ toClose.close();
+ }
+ }
+ }
+
+ /**
* Tests fix for BUG#13453 - can't use & or = in URL configuration
* values (we now allow you to use www-form-encoding).
*
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 6
- Excluding information from results + syntax issueWe are currently running on mysql 4.0-27 at my business. I have what should
seem to be a basic query, but am having trouble with syntax errors and can't
figure out why.
I have two tables (there's more info in each table, but I doubt they're
germaine to the discussion):
users
+---------+-------------+--------------------+
| id | first_name | email |
+---------+-------------+--------------------+
| 1 | Bob | email***@***.com |
| 2 | Fred | email***@***.com |
| 3 | Mark | email***@***.com |
| 4 | Dave | email***@***.com |
+---------+-------------+--------------------+
and
opt
+-----+
| id |
+-----+
| 2 |
| 4 |
+---- +
I am trying to select all the records in users whose ids do not exist in
opt. The ids in both tables are unsigned INTEGER(10). In other words, the
results should be:
+---------+-------------+--------------------+
| id | first_name | email |
+---------+-------------+--------------------+
| 1 | Bob | email***@***.com |
| 3 | Mark | email***@***.com |
+---------+-------------+--------------------+
I have tried the following (not so much the right query as trying to figure
out why none of these queries work on the server):
SELECT * FROM users WHERE id <> ANY (SELECT id FROM opt);
SELECT * FROM users WHERE id IN (SELECT id FROM opt);
SELECT * FROM users WHERE users.id IN (SELECT id FROM opt);
In each case, I get a syntax error. What exactly am I doing wrong?
GregoryD
- 6
- bk commit into 5.1 tree (tomas:1.1884) BUG#12117Below is the list of changes that have just been committed into a local
5.1 repository of tomas. When tomas does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.1884 05/07/23 18:11:10 email***@***.com +9 -0
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
storage/ndb/src/ndbapi/NdbEventOperation.cpp
1.7 05/07/23 18:11:04 email***@***.com +5 -0
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
storage/ndb/src/kernel/blocks/suma/Suma.cpp
1.22 05/07/23 18:11:04 email***@***.com +9 -6
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
storage/ndb/src/kernel/blocks/dbdict/Dbdict.cpp
1.52 05/07/23 18:11:04 email***@***.com +8 -0
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
storage/ndb/include/ndbapi/NdbEventOperation.hpp
1.15 05/07/23 18:11:04 email***@***.com +2 -0
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
storage/ndb/include/kernel/signaldata/SumaImpl.hpp
1.6 05/07/23 18:11:04 email***@***.com +4 -1
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
sql/ha_ndbcluster.h
1.91 05/07/23 18:11:04 email***@***.com +2 -0
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
sql/ha_ndbcluster.cc
1.202 05/07/23 18:11:04 email***@***.com +76 -24
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
mysql-test/t/ndb_alter_table.test
1.24 05/07/23 18:11:04 email***@***.com +0 -3
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
mysql-test/r/ndb_alter_table.result
1.30 05/07/23 18:11:03 email***@***.com +0 -7
Bug #12117 create/drop/alter combinations with several mysql servers can cause server crash
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: tomas
# Host: poseidon.ndb.mysql.com
# Root: /home/tomas/mysql-5.1-wl2325-a
--- 1.29/mysql-test/r/ndb_alter_table.result 2005-07-21 20:35:02 +02:00
+++ 1.30/mysql-test/r/ndb_alter_table.result 2005-07-23 18:11:03 +02:00
@@ -179,13 +179,6 @@
2 two two
alter table t1 drop index c;
select * from t1 where b = 'two';
-ERROR HY000: Table definition has changed, please retry transaction
-show warnings;
-Level Code Message
-Error 1296 Got error 284 'Table not defined in transaction coordinator' from NDB
-Error 1412 Table definition has changed, please retry transaction
-Error 1105 Unknown error
-select * from t1 where b = 'two';
a b c
2 two two
drop table t1;
--- 1.23/mysql-test/t/ndb_alter_table.test 2005-07-21 20:35:03 +02:00
+++ 1.24/mysql-test/t/ndb_alter_table.test 2005-07-23 18:11:04 +02:00
@@ -151,9 +151,6 @@
connection server1;
alter table t1 drop index c;
connection server2;
---error 1412
-select * from t1 where b = 'two';
-show warnings;
select * from t1 where b = 'two';
connection server1;
drop table t1;
--- 1.5/storage/ndb/include/kernel/signaldata/SumaImpl.hpp 2005-07-21 20:35:05 +02:00
+++ 1.6/storage/ndb/include/kernel/signaldata/SumaImpl.hpp 2005-07-23 18:11:04 +02:00
@@ -302,7 +302,10 @@
Uint32 senderData;
Uint32 gci;
Uint32 tableId;
- Uint32 operation;
+ Uint8 operation;
+ Uint8 req_nodeid;
+ Uint8 not_used2;
+ Uint8 not_used3;
Uint32 logType;
};
--- 1.14/storage/ndb/include/ndbapi/NdbEventOperation.hpp 2005-07-21 20:35:06 +02:00
+++ 1.15/storage/ndb/include/ndbapi/NdbEventOperation.hpp 2005-07-23 18:11:04 +02:00
@@ -202,6 +202,8 @@
void clearError();
int hasError() const;
+
+ int getReqNodeId() const;
#endif
#ifndef DOXYGEN_SHOULD_SKIP_INTERNAL
--- 1.51/storage/ndb/src/kernel/blocks/dbdict/Dbdict.cpp 2005-07-22 17:08:45 +02:00
+++ 1.52/storage/ndb/src/kernel/blocks/dbdict/Dbdict.cpp 2005-07-23 18:11:04 +02:00
@@ -3877,6 +3877,10 @@
conf->requestType = AlterTabReq::AlterTableCommit;
{
AlterTabConf tmp= *conf;
+ if (coordinatorRef == reference())
+ conf->senderRef = alterTabPtr.p->m_senderRef;
+ else
+ conf->senderRef = 0;
EXECUTE_DIRECT(SUMA, GSN_ALTER_TAB_CONF, signal,
AlterTabConf::SignalLength);
jamEntry();
@@ -5913,6 +5917,10 @@
conf->tableId = dropTabPtr.p->m_request.tableId;
{
DropTabConf tmp= *conf;
+ if (dropTabPtr.p->m_coordinatorRef == reference())
+ conf->senderRef = dropTabPtr.p->m_request.senderRef;
+ else
+ conf->senderRef = 0;
EXECUTE_DIRECT(SUMA, GSN_DROP_TAB_CONF, signal,
DropTabConf::SignalLength);
jamEntry();
--- 1.21/storage/ndb/src/kernel/blocks/suma/Suma.cpp 2005-07-21 20:35:08 +02:00
+++ 1.22/storage/ndb/src/kernel/blocks/suma/Suma.cpp 2005-07-23 18:11:04 +02:00
@@ -3205,6 +3205,7 @@
ndbassert(signal->getNoOfSections() == 0);
DropTabConf * const conf = (DropTabConf*)signal->getDataPtr();
+ Uint32 senderRef= conf->senderRef;
Uint32 tableId= conf->tableId;
TablePtr tabPtr;
@@ -3225,17 +3226,18 @@
tabPtr.p->m_triggerIds[1] = ILLEGAL_TRIGGER_ID;
tabPtr.p->m_triggerIds[2] = ILLEGAL_TRIGGER_ID;
- if (get_responsible_node(0) != refToNode(reference()))
+ if (senderRef == 0)
{
DBUG_VOID_RETURN;
}
- // responsible for bucket 0 sends info to API
+ // dict coordinator sends info to API
SubTableData * data = (SubTableData*)signal->getDataPtrSend();
data->gci = m_last_complete_gci+1;
data->tableId = tableId;
data->operation = NdbDictionary::Event::_TE_DROP;
-
+ data->req_nodeid = refToNode(senderRef);
+
{
LocalDLList<Subscriber> subbs(c_subscriberPool,tabPtr.p->c_subscribers);
SubscriberPtr subbPtr;
@@ -3253,7 +3255,6 @@
//continue in for-loop if the table is not part of
//the subscription. Otherwise, send data to subscriber.
}
-
data->senderData= subbPtr.p->m_senderData;
sendSignal(subbPtr.p->m_senderRef, GSN_SUB_TABLE_DATA, signal,
SubTableData::SignalLength, JBB);
@@ -3271,6 +3272,7 @@
ndbassert(signal->getNoOfSections() == 0);
AlterTabConf * const conf = (AlterTabConf*)signal->getDataPtr();
+ Uint32 senderRef= conf->senderRef;
Uint32 tableId= conf->tableId;
TablePtr tabPtr;
@@ -3286,16 +3288,17 @@
tabPtr.p->m_state = Table::ALTERED;
// triggers must be removed, waiting for sub stop req for that
- if (get_responsible_node(0) != refToNode(reference()))
+ if (senderRef == 0)
{
DBUG_VOID_RETURN;
}
- // responsible for bucket 0 sends info to API
+ // dict coordinator sends info to API
SubTableData * data = (SubTableData*)signal->getDataPtrSend();
data->gci = m_last_complete_gci+1;
data->tableId = tableId;
data->operation = NdbDictionary::Event::_TE_ALTER;
+ data->req_nodeid = refToNode(senderRef);
{
LocalDLList<Subscriber> subbs(c_subscriberPool,tabPtr.p->c_subscribers);
--- 1.6/storage/ndb/src/ndbapi/NdbEventOperation.cpp 2005-07-21 20:35:09 +02:00
+++ 1.7/storage/ndb/src/ndbapi/NdbEventOperation.cpp 2005-07-23 18:11:04 +02:00
@@ -152,6 +152,11 @@
return m_impl.m_custom_data;
}
+int NdbEventOperation::getReqNodeId() const
+{
+ return m_impl.m_data_item->sdata->req_nodeid;
+}
+
/*
* Private members
*/
--- 1.201/sql/ha_ndbcluster.cc 2005-07-22 03:03:59 +02:00
+++ 1.202/sql/ha_ndbcluster.cc 2005-07-23 18:11:04 +02:00
@@ -121,7 +121,7 @@
static int handle_trailing_share(NDB_SHARE *share);
static int rename_share(NDB_SHARE *share, const char *new_key);
#endif
-static void free_share(NDB_SHARE **share);
+static void free_share(NDB_SHARE **share, bool have_lock= FALSE);
static void real_free_share(NDB_SHARE **share);
static void ndb_set_fragmentation(NDBTAB & tab, TABLE *table, uint pk_len);
@@ -520,29 +520,38 @@
# The mapped error code
*/
-void ha_ndbcluster::invalidate_dictionary_cache(bool global)
+void
+ha_ndbcluster::invalidate_dictionary_cache(TABLE *table, Ndb *ndb,
+ const char *tabname, bool global)
{
- NDBDICT *dict= get_ndb()->getDictionary();
+ NDBDICT *dict= ndb->getDictionary();
DBUG_ENTER("invalidate_dictionary_cache");
- DBUG_PRINT("info", ("invalidating %s", m_tabname));
+ DBUG_PRINT("info", ("invalidating %s", tabname));
if (global)
{
- const NDBTAB *tab= dict->getTable(m_tabname);
+ const NDBTAB *tab= dict->getTable(tabname);
if (!tab)
DBUG_VOID_RETURN;
if (tab->getObjectStatus() == NdbDictionary::Object::Invalid)
{
// Global cache has already been invalidated
- dict->removeCachedTable(m_tabname);
+ dict->removeCachedTable(tabname);
global= FALSE;
}
else
- dict->invalidateTable(m_tabname);
+ dict->invalidateTable(tabname);
}
else
- dict->removeCachedTable(m_tabname);
+ dict->removeCachedTable(tabname);
table->s->version=0L; /* Free when thread is ready */
+ DBUG_VOID_RETURN;
+}
+
+void ha_ndbcluster::invalidate_dictionary_cache(bool global)
+{
+ NDBDICT *dict= get_ndb()->getDictionary();
+ invalidate_dictionary_cache(table, get_ndb(), m_tabname, global);
/* Invalidate indexes */
for (uint i= 0; i < table->s->keys; i++)
{
@@ -574,7 +583,6 @@
break;
}
}
- DBUG_VOID_RETURN;
}
int ha_ndbcluster::ndb_err(NdbTransaction *trans)
@@ -4024,7 +4032,7 @@
#ifdef HAVE_NDB_BINLOG
ndbcluster_create_binlog_setup(get_ndb(), name2, m_dbname, m_tabname,
ndb_binlog_thread_running > 0 &&
- m_tabname[0] != '#');
+ !is_prefix(m_tabname,tmp_file_prefix));
#endif /* HAVE_NDB_BINLOG */
DBUG_RETURN(my_errno);
} // if (create_from_engine)
@@ -4165,7 +4173,7 @@
sql_print_error("NDB: allocating table share for %s failed", name2);
}
- while (m_tabname[0] != '#') // FIXME tabname hack
+ while (!is_prefix(m_tabname,tmp_file_prefix))
{
const NDBTAB *t= dict->getTable(m_tabname);
String event_name(INJECTOR_EVENT_LEN);
@@ -4333,14 +4341,14 @@
dict->forceGCPWait();
}
// handle old table
- if ( m_tabname[0] != '#' ) // FIXME tabname hack
+ if ( !is_prefix(m_tabname,tmp_file_prefix) )
{
String event_name(INJECTOR_EVENT_LEN);
ndb_rep_event_name(&event_name,from+sizeof(share_prefix)-1,0);
ndb_binlog_handle_drop_table(ndb, event_name.c_ptr(), share);
}
- if( !result && new_tabname[0] != '#')
+ if( !result && !is_prefix(new_tabname,tmp_file_prefix) )
{
/* always create an event for the table */
String event_name(INJECTOR_EVENT_LEN);
@@ -4439,12 +4447,14 @@
#ifdef HAVE_NDB_BINLOG
if (share)
{
+ pthread_mutex_lock(&ndbcluster_mutex);
if (share->state != NSS_DROPPED)
{
share->state= NSS_DROPPED;
- free_share(&share);
+ free_share(&share,TRUE);
}
- free_share(&share);
+ free_share(&share,TRUE);
+ pthread_mutex_unlock(&ndbcluster_mutex);
}
#endif
DBUG_RETURN(r);
@@ -4464,7 +4474,7 @@
dict->forceGCPWait();
}
- if ( table_name[0] != '#' ) // FIXME tabname hack
+ if ( !is_prefix(table_name,tmp_file_prefix) )
{
String event_name(INJECTOR_EVENT_LEN);
ndb_rep_event_name(&event_name,path+sizeof(share_prefix)-1,0);
@@ -4475,12 +4485,14 @@
if (share)
{
+ pthread_mutex_lock(&ndbcluster_mutex);
if (share->state != NSS_DROPPED)
{
share->state= NSS_DROPPED;
- free_share(&share);
+ free_share(&share,TRUE);
}
- free_share(&share);
+ free_share(&share,TRUE);
+ pthread_mutex_unlock(&ndbcluster_mutex);
}
#endif
DBUG_RETURN(0);
@@ -5037,7 +5049,7 @@
*/
ndbcluster_create_binlog_setup(ndb, key, t.database, t.name,
ndb_binlog_thread_running > 0 &&
- t.name[0] != '#');
+ !is_prefix(t.name,tmp_file_prefix));
}
#endif
}
@@ -5165,7 +5177,8 @@
// attempt to do it
pthread_mutex_unlock(&ndbcluster_mutex);
- ndbcluster_create_binlog_setup(ndb, name, db, file_name, file_name[0] != '#');
+ ndbcluster_create_binlog_setup(ndb, name, db, file_name,
+ !is_prefix(file_name,tmp_file_prefix));
pthread_mutex_lock(&ndbcluster_mutex);
}
}
@@ -5966,6 +5979,19 @@
static ulong trailing_share_id= 0;
DBUG_ENTER("handle_trailing_share");
+ ++share->use_count;
+ pthread_mutex_unlock(&ndbcluster_mutex);
+
+ close_cached_tables((THD*) 0,0,(TABLE_LIST*) 0);
+
+ pthread_mutex_lock(&ndbcluster_mutex);
+ if (!--share->use_count)
+ {
+ DBUG_PRINT("info", ("NDB_SHARE: close_cashed_tables %s freed share.", share->key));
+ real_free_share(&share);
+ DBUG_RETURN(0);
+ }
+
if (share->state != NSS_DROPPED && !--share->use_count)
{
DBUG_PRINT("info", ("NDB_SHARE: %s already exists, use_count=%d, state != NSS_DROPPED.",
@@ -6254,9 +6280,10 @@
dbug_print_open_tables();
}
-static void free_share(NDB_SHARE **share)
+static void free_share(NDB_SHARE **share, bool have_lock)
{
- pthread_mutex_lock(&ndbcluster_mutex);
+ if (!have_lock)
+ pthread_mutex_lock(&ndbcluster_mutex);
if ((*share)->util_lock == current_thd)
(*share)->util_lock= 0;
if (!--(*share)->use_count)
@@ -6274,7 +6301,8 @@
(*share)->db, (*share)->table_name,
(*share)->use_count, (*share)->commit_count));
}
- pthread_mutex_unlock(&ndbcluster_mutex);
+ if (!have_lock)
+ pthread_mutex_unlock(&ndbcluster_mutex);
}
@@ -9195,6 +9223,7 @@
NDB_SHARE *share= (NDB_SHARE *)pOp->getCustomData();
const NDBTAB *ndbtab= pOp->getTable();
NDBEVENT::TableEvent type= pOp->getEventType();
+ int remote_drop_table= 0, do_close_cached_tables= 0;
switch (type)
{
case NDBEVENT::TE_CLUSTER_FAILURE:
@@ -9225,6 +9254,15 @@
DBUG_PRINT("info",("TABLE %s EVENT: %s received share: 0x%lx op: %lx share op: %lx op_old: %lx",
type == NDBEVENT::TE_DROP ? "DROP" : "ALTER",
ndbtab->getMysqlName(), share, pOp, share->op, share->op_old));
+ if (pOp->getReqNodeId() != ndb_cluster_node_id)
+ {
+ ndb->setDatabaseName(share->table->s->db);
+ ha_ndbcluster::invalidate_dictionary_cache(share->table,
+ ndb,
+ share->table->s->table_name,
+ TRUE);
+ remote_drop_table= 1;
+ }
break;
default:
sql_print_error("NDB Binlog: unknown non data event %d for %s. "
@@ -9244,7 +9282,18 @@
(void) pthread_mutex_unlock(&share->mutex);
(void) pthread_cond_signal(&injector_cond);
- free_share(&share);
+ pthread_mutex_lock(&ndbcluster_mutex);
+ free_share(&share,TRUE);
+ if (remote_drop_table && share && share->state != NSS_DROPPED)
+ {
+ DBUG_PRINT("info",("remote drop table"));
+ if (share->use_count != 1)
+ do_close_cached_tables= 1;
+ share->state= NSS_DROPPED;
+ free_share(&share,TRUE);
+ }
+ pthread_mutex_unlock(&ndbcluster_mutex);
+
share= 0;
pOp->setCustomData(0);
@@ -9252,6 +9301,9 @@
ndb->dropEventOperation(pOp);
pOp= 0;
pthread_mutex_unlock(&injector_mutex);
+
+ if(do_close_cached_tables)
+ close_cached_tables((THD*) 0,0,(TABLE_LIST*) 0);
return 0;
}
--- 1.90/sql/ha_ndbcluster.h 2005-07-21 20:35:03 +02:00
+++ 1.91/sql/ha_ndbcluster.h 2005-07-23 18:11:04 +02:00
@@ -569,6 +569,8 @@
uint key_length,
qc_engine_callback *engine_callback,
ulonglong *engine_data);
+ static void invalidate_dictionary_cache(TABLE *table, Ndb *ndb,
+ const char *tabname, bool global);
private:
friend int ndbcluster_drop_database(const char *path);
int alter_table_name(const char *to);
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 6
- ATTENTION!!!BARRISTER WILLIAMS MOORE(bar_williamsmoore@hotmail.com)WILLIAMS MOORE AND ASSOCIATES
SOLICITOR AND ADVOCATES
NO. 24, JALAN MELAKA RAYA 31,
TAMAN MELAKA RAYA
MALAYSIA
TEL: +60122442893
I am williams Moore ,an attorney at law.A deceased client of mine, that shares the same last name as yours, who here in after shall be referred to as my client, died as the result of a heart-related condition on the 11 November 2001. His heart condition was due to the death of all the members of his family in the Gulf Air Flight Crashes in Persian Gulf Near Bahrain Aired August 23, 2000 - 2:50 p.m. ET as reported on:http://transcripts.cnn.com/TRANSCRIPTS/0008/23/bn.08.html
I have contacted you to assist in distributing the money left behind by my client before it is confiscated or declared unserviceable by the bank where this deposit valued at seventeen million five hundred thousand(US$17.5 million dollars) is lodged. This bank has issued me a notice to contact the next of kin, or the account will be confiscated.
My proposition to you is to seek your consent to present you as the next-of-kin and beneficiary of my named client, since you have the same last name, so that the proceeds of this account can be paid to you. Then we can share the amount on a mutually agreed-upon percentage. All legal documents to back up your claim as my client's next-of-kin will be provided.All I require is your honest cooperation to enable us see this transaction through.
This will be executed under a legitimate arrangement that will protect you from many breach of the law. If this business proposi tion offends your moral values,do accept my apology. I must use this opportunity to implore you to exercise the utmost indulgence to keep this matter extraordinary confidential, whatever your decision, while I await your prompt response.Please contact me at once to indicate your interest. I will like you to acknowledge the receipt of this e-mail as soon as possible via my private EMAIL:(email***@***.com) and treat with absolute confidentiality and sincerity.I look forward to your quick reply.
REPLY VIA (email***@***.com)
Best regards,
williams Moore
Attorney at Law
- 6
- Enforcing Data FormatHello,
Is it possible to enforce data formatting in fields using something like
a regular expression?
varchar is great but does not stop someone putting in the wrong
reference number.
I suspect the answer is no, you have to do it at a higher level. What
aprroach would people suggest?
Perhaps another table with two fields - field_name and field_regex?
Thanks,
Tim.
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
- 6
- LOAD DATA INFILE warningsIs there any way I can see what causes the warnings (and for which
line in my CSV file) when I use LOAD DATA INFILE?
I'm on MySQL 3.23.58 on RH9.
Thanks
- 8
- bk commit - mysqldoc tree (paul:1.2796)Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2796 05/03/31 13:46:47 email***@***.com +1 -0
Typo in variable name.
tools/texi2db
1.28 05/03/31 13:46:46 email***@***.com +1 -1
Typo in variable name.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: kite-hub.kitebird.com
# Root: /src/extern/MySQL/bk/mysqldoc
--- 1.27/tools/texi2db 2005-03-31 12:04:12 -06:00
+++ 1.28/tools/texi2db 2005-03-31 13:46:46 -06:00
@@ -1348,7 +1348,7 @@
} elsif ($replacement eq 'PXREF') {
$replacement = "see " . &crossref();
} elsif ($replacement eq 'UREF') {
- my @params = split(/\s*,\s*/, $contents);
+ my @param = split(/\s*,\s*/, $contents);
$link = $param[0];
$linktitle = $param[2] || $param[1] || $param[0];
$replacement = "\<ulink url='$link'\>$linktitle\<\/ulink\>";
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 10
- newbie help db locked err is The table '#sql_2c52_0' is full [ag]Hy thank you all, I'm getting the following err msg
-> The table '#sql_2c52_0' is full
running a complex query (and only running that query) with three outer join
it is a simple db that stores mail msgs
my query is about mail msg->recipients->sender
the biggest table mail_archive has 90467 rows
I checked every things I know:
-disk space
tables integrity
isam check etc...
my server is-> server version: 4.0.24_Debian-10sarge2-log
all tables are myISAM tables
this snippets is in csv format
output from command:
SHOW TABLE STATUS FROM mydbLIKE 'mail%'
mysql>
"Name","Type","Row_format","Rows","Avg_row_length","Data_length","Max_data_length","Index_length","Data_free","Auto_increment","Create_time","Update_time","Check_time","Create_options","Comment"
"mail_archive","MyISAM","Dynamic",90467,4307,389686660,4294967295,2044928,0,102183,"2006-10-01
02:38:34","2006-10-01 23:15:31","2006-10-01 02:43:55","",""
"mail_attachment_archive","MyISAM","Dynamic",47107,47,2233816,4294967295,1024,0,,"2006-01-20
09:53:26","2006-10-01 23:15:31","","",""
"mail_recipients","MyISAM","Dynamic",682960,51,34918212,4294967295,5704704,19044,,"2006-01-20
09:53:26","2006-10-01 23:15:31","","",""
"mail_senders","MyISAM","Dynamic",49247,50,2497204,4294967295,421888,3560,,"2006-01-20
09:53:26","2006-10-01 23:15:31","2006-03-23 23:53:08","",""
any help would be appreciate.
TIA
ag.
- 13
- [Linker error] undefined reference to `mysqlpp::Connection::~Connection()'------=_NextPart_000_0000_01C62FD3.104C5240
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
hi everyone... i wrote a REALY simple program ;)
#include "mysql++.h"
int main( int argc, char* argv[] )
{
mysqlpp::Connection con;
}
when i try to compile it i get the following errors:
[Linker error] undefined reference to `_imp___ZN7mysqlpp10ConnectionC1Eb'
[Linker error] undefined reference to `mysqlpp::Connection::~Connection()'
ld returned 1 exit status
i put mysql/include and mysql++/lib folder in the project settings...
and i linked mysqlpp.lib
what's wrong?
Goddchen
------=_NextPart_000_0000_01C62FD3.104C5240--
- 13
- com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception:Hi,
I have a problem connecting from JDBC in Windows, when I try to execute:
conn = DriverManager.getConnection("jdbc:mysql://"
+ pref.getProperty("dbms.host")
+ ":" + pref.getProperty("dbms.port")
+ "/" + pref.getProperty("dbms.sid")
+ "?user=" + user + "&password=" +
pwd.toString()
+ "&autoReconnect=true");
I get this exception:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
com.mysql.jdbc.CommunicationsException: Communications link failure due to
under
lying exception:
** BEGIN NESTED EXCEPTION **
java.io.EOFException
STACKTRACE:
java.io.EOFException
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1895)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2342)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2838)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:773)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3612)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1204)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:1699)
at com.mysql.jdbc.Connection.<init>(Connection.java:408)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java
:270)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at bb.db.Connection.<init>(Connection.java:71)
at bb.Main.<init>(Main.java:34)
at bb.Main.createAndShowMainFrame(Main.java:71)
at bb.Main$1.run(Main.java:105)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
** END NESTED EXCEPTION **
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2554)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2838)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:773)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3612)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1204)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:1699)
at com.mysql.jdbc.Connection.<init>(Connection.java:408)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java
:270)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at bb.db.Connection.<init>(Connection.java:71)
at bb.Main.<init>(Main.java:34)
at bb.Main.createAndShowMainFrame(Main.java:71)
at bb.Main$1.run(Main.java:105)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I saw this thread:
http://forums.mysql.com/read.php?39,16257,16257#msg-16257
in the forums... but any of the proposed solutions there apply to my case
since I try connecting from the same windows machine using MySQL
Administrator and I can get a connection from it...
The java version used for the application is:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ java -version
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And MySQL's J/Connector version is: mysql-connector-java-3.1.8-bin.jar
I'm connecting to a MySQL server:
mysql Ver 14.9 Distrib 5.0.3-beta, for portbld-freebsd5.3 (i386)
Is there a bug or any in J/Connector or something like that? (I've already
tryed with J/Connector versions 3.0 or 3.2 but neither correct the problem..
Thanks a lot in advance for any help.
Regards,
Ed.
--
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe: http://lists.mysql.com/java?unsub=email***@***.com
- 16
- bk commit into 5.0 tree (jimw:1.1953)Below is the list of changes that have just been committed into a local
5.0 repository of jimw. When jimw does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.1953 05/10/28 10:17:37 email***@***.com +1 -0
Merge bk-internal:/home/bk/mysql-5.0
into mysql.com:/home/jimw/my/mysql-5.0-clean
sql/item_func.cc
1.265 05/10/28 10:17:33 email***@***.com +0 -0
Auto merged
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jimw
# Host: rama.(none)
# Root: /home/jimw/my/mysql-5.0-clean/RESYNC
--- 1.264/sql/item_func.cc 2005-10-27 14:56:37 -07:00
+++ 1.265/sql/item_func.cc 2005-10-28 10:17:33 -07:00
@@ -636,6 +636,7 @@
{
decimals= args[0]->decimals;
max_length= args[0]->max_length;
+ maybe_null= 1;
}
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 16
- setLong not working the same as inlined numbersI'm running mysql 4.1.1 on linux with
mysql-connector-java-3.1-nightly-20040206
When I use setLong to set parameters there's something that doesn't seem
to be working, it's not giving the correct result where if I put the
numbers inlined with the statment it seems to be working.
below is the smallest code snipped I can produce to repoduce the problem,
when I run the below code, I get a print out of parameter:true,
inline:false, both answers should be the same and both should be false. Am
I missing something here?
Connection c=getConnection();
PreparedStatement ps;
ps=c.prepareStatement("CREATE TABLE FOO (CONNECTION_ID VARCHAR(25), START_DATE BIGINT)");
ps.executeUpdate();
ps.close();
ps=c.prepareStatement("INSERT INTO FOO (CONNECTION_ID, START_DATE) VALUES ('192.168.1.1',5555555),('192.168.1.1',7355555)");
ps.executeUpdate();
ps.close();
ps=c.prepareStatement("SELECT * FROM FOO WHERE START_DATE>=? AND START_DATE<=?");
ps.setLong(1, 1905555l);
ps.setLong(2, 5505555l);
rs=ps.executeQuery();
System.out.println("parameter:"+rs.next());
rs.close();
ps.close();
ps=c.prepareStatement("SELECT * FROM FOO WHERE START_DATE>="+1905555l+" AND START_DATE<="+5505555l);
rs=ps.executeQuery();
System.out.println("inline:"+rs.next());
rs.close();
ps.close();
--
Being normal is vastly over rated : Ted Leung
email***@***.com
--
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe: http://lists.mysql.com/java?unsub=email***@***.com
|
| Author |
Message |
paul
|
 Posted: 2005-8-16 3:12:52 |
Top |
mysql, bk commit - mysqldoc@docsrva tree (paul:1.3282)
Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3282 05/08/15 14:12:17 email***@***.com +4 -0
De-cruft.
refman/mysql-optimization.xml
1.10 05/08/15 14:12:17 email***@***.com +40 -58
De-cruft.
refman-5.1/mysql-optimization.xml
1.6 05/08/15 14:12:17 email***@***.com +96 -107
De-cruft.
refman-5.0/mysql-optimization.xml
1.6 05/08/15 14:12:16 email***@***.com +96 -107
De-cruft.
refman-4.1/mysql-optimization.xml
1.11 05/08/15 14:12:16 email***@***.com +206 -199
De-cruft.
refman/mysql-optimization.xml
1.9 05/08/15 14:00:44 email***@***.com +8 -12
refman-5.1/mysql-optimization.xml
1.5 05/08/15 14:00:44 email***@***.com +8 -12
refman-5.0/mysql-optimization.xml
1.5 05/08/15 14:00:44 email***@***.com +8 -12
refman-4.1/mysql-optimization.xml
1.10 05/08/15 14:00:43 email***@***.com +8 -12
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: kite-hub.kitebird.com
# Root: /src/extern/MySQL/bk/mysqldoc
--- 1.4/refman-5.1/mysql-optimization.xml 2005-08-10 05:44:19 -05:00
+++ 1.6/refman-5.1/mysql-optimization.xml 2005-08-15 14:12:17 -05:00
@@ -925,16 +925,16 @@
<itemizedlist>
- <indexterm type="concept">
- <primary>system table</primary>
- </indexterm>
+ <listitem>
+ <indexterm type="concept">
+ <primary>system table</primary>
+ </indexterm>
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>system</secondary>
- </indexterm>
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>system</secondary>
+ </indexterm>
- <listitem>
<para>
<literal>system</literal>
</para>
@@ -943,20 +943,18 @@
The table has only one row (= system table). This is a
special case of the <literal>const</literal> join type.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>constant table</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>constant</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>constant table</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>constant</secondary>
+ </indexterm>
+
<para>
<literal>const</literal>
</para>
@@ -979,14 +977,12 @@
<literal>const</literal> table:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1018,7 +1014,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>;
@@ -1027,7 +1022,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1061,7 +1055,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
@@ -1072,7 +1065,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1094,12 +1086,10 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>
WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
</programlisting>
- </para>
<para>
See <xref linkend="is-null-optimization"/>.
@@ -1130,11 +1120,13 @@
<para>
This type replaces <literal>ref</literal> for some
<literal>IN</literal> subqueries of the following form:
+ </para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>primary_key</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
+ <para>
<literal>unique_subquery</literal> is just an index
lookup function that replaces the subquery completely
for better efficiency.
@@ -1153,11 +1145,9 @@
non-unique indexes in subqueries of the following form:
</para>
- <para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>key_column</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1186,7 +1176,6 @@
operators:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_column</replaceable> = 10;
@@ -1200,7 +1189,6 @@
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1328,7 +1316,7 @@
</listitem>
<!--
- TODO: We don't seem to explain what ref values of "const", NULL,
+ TODO: We do not seem to explain what ref values of "const", NULL,
or <replaceable>tbl_name.col_name</replaceable> mean.
-->
@@ -1385,12 +1373,10 @@
optimized this way:
</para>
- <para>
<programlisting>
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
</programlisting>
- </para>
<para>
Assume that <literal>t2.id</literal> is defined as
@@ -2004,35 +1990,35 @@
<listitem>
<para>
Removal of unnecessary parentheses:
+ </para>
<programlisting>
((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant folding:
+ </para>
<programlisting>
(a<b AND b=c) AND a=5
-> b>5 AND b=c AND a=5
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant condition removal (needed because of constant
folding):
+ </para>
<programlisting>
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6
</programlisting>
- </para>
</listitem>
<listitem>
@@ -3536,40 +3522,42 @@
the columns required for the query as well. This avoids reading
the rows twice. The <literal>filesort</literal> algorithm works
like this:
+ </para>
- <orderedlist>
+ <orderedlist>
- <listitem>
- <para>
- Read the rows that match the <literal>WHERE</literal>
- clause, as before.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Read the rows that match the <literal>WHERE</literal>
+ clause, as before.
+ </para>
+ </listitem>
- <listitem>
- <para>
- For each row, record a tuple of values consisting of the
- sort key value and row position, and also the columns
- required for the query.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ For each row, record a tuple of values consisting of the
+ sort key value and row position, and also the columns
+ required for the query.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Sort the tuples by sort key value
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Sort the tuples by sort key value
+ </para>
+ </listitem>
- <listitem>
- <para>
- Retrieve the rows in sorted order, but read the required
- columns directly from the sorted tuples rather than by
- accessing the table a second time.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Retrieve the rows in sorted order, but read the required
+ columns directly from the sorted tuples rather than by
+ accessing the table a second time.
+ </para>
+ </listitem>
- </orderedlist>
+ </orderedlist>
+ <para>
This algorithm represents an improvement over that used in some
older versions of MySQL.
</para>
@@ -4507,17 +4495,16 @@
important for you, you should consider using the table in
ways that avoid deleting rows. Another possibility is to run
<literal>OPTIMIZE TABLE</literal> after you have deleted a
- lot of rows.
- See <xref linkend="myisam-storage-engine"/>.
+ lot of rows. See <xref linkend="myisam-storage-engine"/>.
</para>
</listitem>
<listitem>
<para>
- To fix any compression issues that may have occurred
- with <literal>ARCHIVE</literal> tables
- you can always do an <literal>OPTIMIZE TABLE</literal>.
- See <xref linkend="archive-storage-engine"/>.
+ To fix any compression issues that may have occurred with
+ <literal>ARCHIVE</literal> tables you can always do an
+ <literal>OPTIMIZE TABLE</literal>. See
+ <xref linkend="archive-storage-engine"/>.
</para>
</listitem>
@@ -5154,42 +5141,42 @@
<para>
Options other than row-level or page-level locking:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Versioning (such as that used in MySQL for concurrent
- inserts) where it is possible to have one writer at the
- same time as many readers. This means that the database or
- table supports different views for the data depending on
- when access begins. Other common terms for this are
- <quote>time travel</quote>, <quote>copy on write</quote>,
- or <quote>copy on demand</quote>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Versioning (such as that used in MySQL for concurrent
+ inserts) where it is possible to have one writer at the same
+ time as many readers. This means that the database or table
+ supports different views for the data depending on when
+ access begins. Other common terms for this are <quote>time
+ travel</quote>, <quote>copy on write</quote>, or <quote>copy
+ on demand</quote>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Copy on demand is in many cases superior to page-level or
- row-level locking. However, in the worst case, it can use
- much more memory than using normal locks.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Copy on demand is in many cases superior to page-level or
+ row-level locking. However, in the worst case, it can use
+ much more memory than using normal locks.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Instead of using row-level locks, you can employ
- application-level locks, such as
- <literal>GET_LOCK()</literal> and
- <literal>RELEASE_LOCK()</literal> in MySQL. These are
- advisory locks, so they work only in well-behaved
- applications.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Instead of using row-level locks, you can employ
+ application-level locks, such as
+ <literal>GET_LOCK()</literal> and
+ <literal>RELEASE_LOCK()</literal> in MySQL. These are
+ advisory locks, so they work only in well-behaved
+ applications.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
</section>
@@ -6133,12 +6120,12 @@
<para>
The following <literal>SELECT</literal> statements do
<emphasis>not</emphasis> use indexes:
+ </para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE '%Patrick%';
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE <replaceable>other_col</replaceable>;
</programlisting>
- </para>
<para>
In the first statement, the <literal>LIKE</literal> value begins
@@ -6185,6 +6172,7 @@
<para>
The following <literal>WHERE</literal> clauses use indexes:
+ </para>
<programlisting>
... WHERE <replaceable>index_part1</replaceable>=1 AND <replaceable>index_part2</replaceable>=2 AND <replaceable>other_column</replaceable>=3
@@ -6195,7 +6183,6 @@
/* Can use index on <replaceable>index1</replaceable> but not on <replaceable>index2</replaceable> or <replaceable>index3</replaceable> */
... WHERE <replaceable>index1</replaceable>=1 AND <replaceable>index2</replaceable>=2 OR <replaceable>index1</replaceable>=3 AND <replaceable>index3</replaceable>=3;
</programlisting>
- </para>
<para>
These <literal>WHERE</literal> clauses do
@@ -6523,6 +6510,7 @@
<para>
Note that you cannot destroy the default key cache. An attempt
to do this will be ignored:
+ </para>
<programlisting>
mysql> <userinput>set global key_buffer_size = 0;</userinput>
@@ -6534,7 +6522,6 @@
| key_buffer_size | 8384512 |
+-----------------+---------+
</programlisting>
- </para>
<para>
Key cache variables are structured system variables that have
@@ -8234,16 +8221,14 @@
better, assuming that the disk is not used for other
purposes as well. See <xref linkend="symbolic-links"/>.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>striping</primary>
- <secondary>defined</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>striping</primary>
+ <secondary>defined</secondary>
+ </indexterm>
+
<para>
Striping
</para>
--- 1.9/refman-4.1/mysql-optimization.xml 2005-08-12 05:57:41 -05:00
+++ 1.11/refman-4.1/mysql-optimization.xml 2005-08-15 14:12:16 -05:00
@@ -273,7 +273,7 @@
<para>
With MySQL, you can use the <literal>/*! */</literal> syntax to
add MySQL-specific keywords to a query. The code inside
- <literal>/* */</literal> is treated as a comment (and ignored)
+ <literal>/* */</literal> is treated as a comment (and ignored)
by most other SQL servers.
</para>
@@ -917,16 +917,16 @@
<itemizedlist>
- <indexterm type="concept">
- <primary>system table</primary>
- </indexterm>
+ <listitem>
+ <indexterm type="concept">
+ <primary>system table</primary>
+ </indexterm>
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>system</secondary>
- </indexterm>
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>system</secondary>
+ </indexterm>
- <listitem>
<para>
<literal>system</literal>
</para>
@@ -935,20 +935,18 @@
The table has only one row (= system table). This is a
special case of the <literal>const</literal> join type.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>constant table</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>constant</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>constant table</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>constant</secondary>
+ </indexterm>
+
<para>
<literal>const</literal>
</para>
@@ -971,14 +969,12 @@
<literal>const</literal> table:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1010,7 +1006,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>;
@@ -1019,7 +1014,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1039,9 +1033,7 @@
a good join type.
</para>
- <para>
<!-- NOTE: The "or <=>" applies only to ref, not to eq_ref. -->
- </para>
<para>
<literal>ref</literal> can be used for indexed columns
@@ -1055,7 +1047,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
@@ -1066,7 +1057,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1078,8 +1068,8 @@
This join type is like <literal>ref</literal>, but with
the addition that MySQL does an extra search for rows
that contain <literal>NULL</literal> values. This join
- type optimization was added for MySQL 4.1.1 and is
- used mostly when resolving subqueries.
+ type optimization was added for MySQL 4.1.1 and is used
+ mostly when resolving subqueries.
</para>
<para>
@@ -1088,12 +1078,10 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>
WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
</programlisting>
- </para>
<para>
See <xref linkend="is-null-optimization"/>.
@@ -1108,11 +1096,13 @@
<para>
This type replaces <literal>ref</literal> for some
<literal>IN</literal> subqueries of the following form:
+ </para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>primary_key</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
+ <para>
<literal>unique_subquery</literal> is just an index
lookup function that replaces the subquery completely
for better efficiency.
@@ -1131,11 +1121,9 @@
non-unique indexes in subqueries of the following form:
</para>
- <para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>key_column</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1164,7 +1152,6 @@
operators:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_column</replaceable> = 10;
@@ -1178,7 +1165,6 @@
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1304,7 +1290,7 @@
rows from the table.
</para>
</listitem>
-
+
<!--
TODO: We do not seem to explain what ref values of "const", NULL,
or @var{tbl_name.col_name} mean.
@@ -1363,12 +1349,10 @@
optimized this way:
</para>
- <para>
<programlisting>
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
</programlisting>
- </para>
<para>
Assume that <literal>t2.id</literal> is defined as
@@ -1401,8 +1385,8 @@
preceding tables, MySQL checks whether it is possible to
use a <literal>range</literal> access method to retrieve
rows. The applicability criteria are as described in
- <xref linkend="range-optimization"/>, with the exception
- that all column values for the preceding table are known
+ <xref linkend="range-optimization"/>, with the exception
+ that all column values for the preceding table are known
and considered to be constants.
</para>
@@ -1953,8 +1937,8 @@
<para>
Note that work on the MySQL optimizer is ongoing, so this
- section is incomplete. MySQL performs a great many
- optimizations, not all of which are documented here.
+ section is incomplete. MySQL performs a great many
+ optimizations, not all of which are documented here.
</para>
<para>
@@ -1966,35 +1950,35 @@
<listitem>
<para>
Removal of unnecessary parentheses:
+ </para>
<programlisting>
((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant folding:
+ </para>
<programlisting>
(a<b AND b=c) AND a=5
-> b>5 AND b=c AND a=5
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant condition removal (needed because of constant
folding):
+ </para>
<programlisting>
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6
</programlisting>
- </para>
</listitem>
<listitem>
@@ -2441,8 +2425,8 @@
<para>
The range condition extraction algorithm can handle nested
<literal>AND</literal>/<literal>OR</literal> constructs of
- arbitrary depth, and its output does not depend on the order in
- which conditions appear in <literal>WHERE</literal> clause.
+ arbitrary depth, and its output does not depend on the order
+ in which conditions appear in <literal>WHERE</literal> clause.
</para>
</section>
@@ -2561,7 +2545,7 @@
<literal>BETWEEN</literal>, or <literal>LIKE
'<replaceable>pattern</replaceable>'</literal> (where
<literal>'<replaceable>pattern</replaceable>'</literal>
- does not start with a wildcard). An interval can be used
+ does not start with a wildcard). An interval can be used
as long as it is possible to determine a single key tuple
containing all records that match the condition (or two
intervals if <literal><></literal> or
@@ -2836,9 +2820,9 @@
</para>
<para>
- If you do not use columns from all tables named in a query, MySQL
- stops scanning the not-used tables as soon as it finds the first
- match. In the following case, assuming that
+ If you do not use columns from all tables named in a query,
+ MySQL stops scanning the not-used tables as soon as it finds the
+ first match. In the following case, assuming that
<literal>t1</literal> is used before <literal>t2</literal>
(which you can check with <literal>EXPLAIN</literal>), MySQL
stops reading from <literal>t2</literal> (for any particular row
@@ -2866,7 +2850,7 @@
</indexterm>
<para>
- An <literal>A LEFT JOIN B</literal> join_condition is
+ An <literal>A LEFT JOIN B</literal> join_condition is
implemented in MySQL as follows:
</para>
@@ -2899,9 +2883,9 @@
<listitem>
<para>
- All standard join optimizations are performed, with the
- exception that a table is always read after all tables on
- which it depends. If there is a circular dependence, MySQL
+ All standard join optimizations are performed, with the
+ exception that a table is always read after all tables on
+ which it depends. If there is a circular dependence, MySQL
issues an error.
</para>
</listitem>
@@ -2925,8 +2909,8 @@
<listitem>
<para>
- If you use <literal>LEFT JOIN</literal> to find rows that
- do not exist in some table and you have the following test:
+ If you use <literal>LEFT JOIN</literal> to find rows that do
+ not exist in some table and you have the following test:
<literal><replaceable>col_name</replaceable> IS
NULL</literal> in the <literal>WHERE</literal> part, where
<replaceable>col_name</replaceable> is a column that is
@@ -3019,8 +3003,8 @@
<para>
The index can also be used even if the <literal>ORDER
- BY</literal> does not match the index exactly, as long as all the
- unused index parts and all the extra are <literal>ORDER
+ BY</literal> does not match the index exactly, as long as all
+ the unused index parts and all the extra are <literal>ORDER
BY</literal> columns are constants in the
<literal>WHERE</literal> clause. The following queries use the
index to resolve the <literal>ORDER BY</literal> part:
@@ -3139,8 +3123,8 @@
</indexterm>
<para>
- Prior to MySQL 4.1, in those cases where MySQL must sort the
- result, it uses the following <literal>filesort</literal>
+ Prior to MySQL 4.1, in those cases where MySQL must sort the
+ result, it uses the following <literal>filesort</literal>
algorithm:
</para>
@@ -3948,8 +3932,8 @@
<listitem>
<para>
- If you intend only to read the table in the future, use
- <command>myisampack</command> to make it smaller. See
+ If you intend only to read the table in the future, use
+ <command>myisampack</command> to make it smaller. See
<xref linkend="compressed-format"/>.
</para>
</listitem>
@@ -4000,7 +3984,7 @@
<listitem>
<para>
You can speed up <literal>INSERT</literal> operations that
- are performed with multiple statements by locking your
+ are performed with multiple statements by locking your
tables:
</para>
@@ -4023,8 +4007,8 @@
<para>
For transactional tables, you should use
- <literal>BEGIN</literal> and <literal>COMMIT</literal>
- instead of <literal>LOCK TABLES</literal> to get a speed
+ <literal>BEGIN</literal> and <literal>COMMIT</literal>
+ instead of <literal>LOCK TABLES</literal> to get a speed
increase.
</para>
@@ -4087,17 +4071,17 @@
<title id='title-update-speed'>&title-update-speed;</title>
<para>
- An update statement is optimized like a
- <literal>SELECT</literal> query with the additional overhead of
- a write. The speed of the write depends on the amount of data
- being updated and the number of indexes that are updated.
+ An update statement is optimized like a
+ <literal>SELECT</literal> query with the additional overhead of
+ a write. The speed of the write depends on the amount of data
+ being updated and the number of indexes that are updated.
Indexes that are not changed do not get updated.
</para>
<para>
Also, another way to get fast updates is to delay updates and
- then do many updates in a row later. Performing multiple updates
- together is much quicker than doing one at a time if you lock
+ then do many updates in a row later. Performing multiple updates
+ together is much quicker than doing one at a time if you lock
the table.
</para>
@@ -4116,15 +4100,15 @@
<title id='title-delete-speed'>&title-delete-speed;</title>
<para>
- The time required to delete individual records is exactly
- proportional to the number of indexes. To delete records more
+ The time required to delete individual records is exactly
+ proportional to the number of indexes. To delete records more
quickly, you can increase the size of the key cache. See
<xref linkend="server-parameters"/>.
</para>
<para>
If you want to delete all rows in the table, use
- <literal>TRUNCATE TABLE
+ <literal>TRUNCATE TABLE
<replaceable>tbl_name</replaceable></literal> rather than
<literal>DELETE FROM
<replaceable>tbl_name</replaceable></literal>. See
@@ -4157,9 +4141,9 @@
<listitem>
<para>
Use persistent connections to the database to avoid
- connection overhead. If you cannot use persistent connections
- and you are initiating many new connections to the database,
- you may want to change the value of the
+ connection overhead. If you cannot use persistent
+ connections and you are initiating many new connections to
+ the database, you may want to change the value of the
<literal>thread_cache_size</literal> variable. See
<xref linkend="server-parameters"/>.
</para>
@@ -4197,10 +4181,10 @@
<listitem>
<para>
- To fix any compression issues that may have occurred
- with <literal>ARCHIVE</literal> tables
- you can always do an <literal>OPTIMIZE TABLE</literal>.
- See <xref linkend="archive-storage-engine"/>.
+ To fix any compression issues that may have occurred with
+ <literal>ARCHIVE</literal> tables you can always do an
+ <literal>OPTIMIZE TABLE</literal>. See
+ <xref linkend="archive-storage-engine"/>.
</para>
</listitem>
@@ -4235,7 +4219,7 @@
<listitem>
<para>
- For <literal>MyISAM</literal> tables that change frequently,
+ For <literal>MyISAM</literal> tables that change frequently,
you should try to avoid all variable-length columns
(<literal>VARCHAR</literal>, <literal>BLOB</literal>, and
<literal>TEXT</literal>). The table uses dynamic record
@@ -4247,15 +4231,15 @@
<listitem>
<para>
It is normally not useful to split a table into different
- tables just because the rows become large. In accessing a
- row, the biggest performance hit is the disk seek needed to
- find the first byte of the row. After finding the data, most
- modern disks can read the entire row fast enough for most
- applications. The only cases where splitting up a table
- makes an appreciable difference is if it is a
- <literal>MyISAM</literal> table using dynamic record format
- (see above) that you can change to a fixed record size, or
- if you very often need to scan the table but do not need
+ tables just because the rows become large. In accessing a
+ row, the biggest performance hit is the disk seek needed to
+ find the first byte of the row. After finding the data, most
+ modern disks can read the entire row fast enough for most
+ applications. The only cases where splitting up a table
+ makes an appreciable difference is if it is a
+ <literal>MyISAM</literal> table using dynamic record format
+ (see above) that you can change to a fixed record size, or
+ if you very often need to scan the table but do not need
most of the columns. See <xref linkend="storage-engines"/>.
</para>
</listitem>
@@ -4276,8 +4260,8 @@
This is really important when you use MySQL storage engines
such as <literal>MyISAM</literal> and
<literal>ISAM</literal> that have only table-level locking
- (multiple readers with single writers). This also gives
- better performance with most databases, because the row
+ (multiple readers with single writers). This also gives
+ better performance with most databases, because the row
locking manager in this case has less to do.
</para>
</listitem>
@@ -4315,8 +4299,8 @@
<listitem>
<para>
- In some cases, it is convenient to pack and store data into a
- <literal>BLOB</literal> column. In this case, you must add
+ In some cases, it is convenient to pack and store data into
+ a <literal>BLOB</literal> column. In this case, you must add
some extra code in your application to pack and unpack
information in the <literal>BLOB</literal> values, but this
may save a lot of accesses at some stage. This is practical
@@ -4328,9 +4312,12 @@
<listitem>
<para>
Normally, you should try to keep all data non-redundant
- (known as <firstterm>third normal form</firstterm> in
- database theory). However, do not be afraid to duplicate
- information or create summary tables if necessary to gain
+ (known as
+
+ <firstterm>third normal form</firstterm>
+
+ in database theory). However, do not be afraid to duplicate
+ information or create summary tables if necessary to gain
more speed.
</para>
</listitem>
@@ -4415,8 +4402,8 @@
<listitem>
<para>
- Use <literal>MEMORY</literal> (<literal>HEAP</literal>)
- tables when possible to get more speed. See
+ Use <literal>MEMORY</literal> (<literal>HEAP</literal>)
+ tables when possible to get more speed. See
<xref linkend="memory-storage-engine"/>.
</para>
</listitem>
@@ -4424,10 +4411,10 @@
<listitem>
<para>
When using a normal Web server setup, images should be
- stored as files. That is, only a reference to each file
- should be stored in the database. The main reason for this
- is that a normal Web server is much better at caching files
- than database contents, so it is much easier to get a fast
+ stored as files. That is, only a reference to each file
+ should be stored in the database. The main reason for this
+ is that a normal Web server is much better at caching files
+ than database contents, so it is much easier to get a fast
system if you are using files.
</para>
</listitem>
@@ -4580,8 +4567,8 @@
<para>
In many cases, you can make an educated guess about which
- locking type is best for an application, but generally it is very
- hard to say that a given lock type is better than another.
+ locking type is best for an application, but generally it is
+ very hard to say that a given lock type is better than another.
Everything depends on the application and different parts of an
application may require different lock types.
</para>
@@ -4778,7 +4765,7 @@
<listitem>
<para>
- With higher-level locks, you can also more easily tune
+ With higher-level locks, you can also more easily tune
applications by supporting locks of different types, because
the lock overhead is less than for row-level locks.
</para>
@@ -5119,7 +5106,9 @@
<indexterm type="concept">
<primary>storage of data</primary>
</indexterm>
+
<!-- TODO: This needs review and possible correction. -->
+
<para>
MySQL keeps row data and index data in separate files. Many
(almost all) other databases mix row and index data in the same
@@ -5224,9 +5213,9 @@
</para>
<para>
- MySQL supports many different storage engines (table types) and
- row formats. For each table, you can decide which storage and
- indexing method to use. Choosing the right table format for your
+ MySQL supports many different storage engines (table types) and
+ row formats. For each table, you can decide which storage and
+ indexing method to use. Choosing the right table format for your
application may give you a big performance gain. See
<xref linkend="storage-engines"/>.
</para>
@@ -5277,7 +5266,7 @@
<literal>ROW_FORMAT=fixed</literal>.
</para>
</listitem>
-
+
<listitem>
<para>
The primary index of a table should be as short as possible.
@@ -5300,10 +5289,10 @@
<listitem>
<para>
- If it is very likely that a column has a unique prefix on the
- first number of characters, it is better to index only this
- prefix. MySQL supports an index on the leftmost part of a
- character column. Shorter indexes are faster not only
+ If it is very likely that a column has a unique prefix on
+ the first number of characters, it is better to index only
+ this prefix. MySQL supports an index on the leftmost part of
+ a character column. Shorter indexes are faster not only
because they take less disk space, but also because they
give you more hits in the index cache and thus fewer disk
seeks. See <xref linkend="server-parameters"/>.
@@ -5312,10 +5301,10 @@
<listitem>
<para>
- In some circumstances, it can be beneficial to split in two
- a table that is scanned very often. This is especially true
- if it is a dynamic format table and it is possible to use a
- smaller static format table that can be used to find the
+ In some circumstances, it can be beneficial to split in two
+ a table that is scanned very often. This is especially true
+ if it is a dynamic format table and it is possible to use a
+ smaller static format table that can be used to find the
relevant rows when scanning the table.
</para>
</listitem>
@@ -5525,7 +5514,7 @@
<para>
The manner in which MySQL uses indexes to improve query
- performance is discussed further in
+ performance is discussed further in
<xref linkend="mysql-indexes"/>.
</para>
@@ -5704,8 +5693,8 @@
<para>
If an index exists on <literal>(col1, col2, col3)</literal>,
- only the first two queries use the index. The third and fourth
- queries do involve indexed columns, but
+ only the first two queries use the index. The third and fourth
+ queries do involve indexed columns, but
<literal>(col2)</literal> and <literal>(col2, col3)</literal>
are not leftmost prefixes of <literal>(col1, col2,
col3)</literal>.
@@ -5759,12 +5748,12 @@
<para>
The following <literal>SELECT</literal> statements do not use
indexes:
+ </para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE '%Patrick%';
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE <replaceable>other_col</replaceable>;
</programlisting>
- </para>
<para>
In the first statement, the <literal>LIKE</literal> value begins
@@ -5773,13 +5762,17 @@
</para>
<para>
- MySQL 4.0 and later versions perform an additional
- <literal>LIKE</literal> optimization. If you use <literal>...
+ MySQL 4.0 and later versions perform an additional
+ <literal>LIKE</literal> optimization. If you use <literal>...
LIKE '%<replaceable>string</replaceable>%'</literal> and
<replaceable>string</replaceable> is longer than three
- characters, MySQL uses the <firstterm>Turbo Boyer-Moore
- algorithm</firstterm> to initialize the pattern for the string
- and then uses this pattern to perform the search more quickly.
+ characters, MySQL uses the
+
+ <firstterm>Turbo Boyer-Moore
+ algorithm</firstterm>
+
+ to initialize the pattern for the string and then uses this
+ pattern to perform the search more quickly.
</para>
<indexterm type="function">
@@ -5799,14 +5792,15 @@
</para>
<para>
- Any index that does not span all <literal>AND</literal> levels in
- the <literal>WHERE</literal> clause is not used to optimize the
- query. In other words, to be able to use an index, a prefix of
- the index must be used in every <literal>AND</literal> group.
+ Any index that does not span all <literal>AND</literal> levels
+ in the <literal>WHERE</literal> clause is not used to optimize
+ the query. In other words, to be able to use an index, a prefix
+ of the index must be used in every <literal>AND</literal> group.
</para>
<para>
The following <literal>WHERE</literal> clauses use indexes:
+ </para>
<programlisting>
... WHERE <replaceable>index_part1</replaceable>=1 AND <replaceable>index_part2</replaceable>=2 AND <replaceable>other_column</replaceable>=3
@@ -5817,7 +5811,6 @@
/* Can use index on <replaceable>index1</replaceable> but not on <replaceable>index2</replaceable> or <replaceable>index3</replaceable> */
... WHERE <replaceable>index1</replaceable>=1 AND <replaceable>index2</replaceable>=2 OR <replaceable>index1</replaceable>=3 AND <replaceable>index3</replaceable>=3;
</programlisting>
- </para>
<para>
These <literal>WHERE</literal> clauses do
@@ -5921,11 +5914,17 @@
<listitem>
<para>
- For index blocks, a special structure called the
- <firstterm>key cache</firstterm> (or <firstterm>key
- buffer</firstterm>) is maintained. The structure contains a
- number of block buffers where the most-used index blocks are
- placed.
+ For index blocks, a special structure called the
+
+ <firstterm>key cache</firstterm>
+
+ (or
+
+ <firstterm>key
+ buffer</firstterm>
+
+ ) is maintained. The structure contains a number of block
+ buffers where the most-used index blocks are placed.
</para>
</listitem>
@@ -5969,7 +5968,7 @@
<literal>ISAM</literal> table use has been decreasing since
MySQL 3.23 when <literal>MyISAM</literal> was introduced. MySQL
4.1 carries this trend further; the <literal>ISAM</literal>
- storage engine is disabled by default. (Subsequent MySQL release
+ storage engine is disabled by default. (Subsequent MySQL release
series have no support at all for <literal>ISAM</literal>.)
</para>
@@ -6026,15 +6025,21 @@
</para>
<para>
- Usually the server follows an <firstterm>LRU (Least Recently
- Used)</firstterm> strategy: When choosing a block for
- replacement, it selects the least recently used index block. To
- make this choice easier, the key cache module maintains a
- special queue (<firstterm>LRU chain</firstterm>) of all used
- blocks. When a block is accessed, it is placed at the end of the
- queue. When blocks need to be replaced, blocks at the beginning
- of the queue are the least recently used and become the first
- candidates for eviction.
+ Usually the server follows an
+
+ <firstterm>LRU (Least Recently
+ Used)</firstterm>
+
+ strategy: When choosing a block for replacement, it selects the
+ least recently used index block. To make this choice easier, the
+ key cache module maintains a special queue (
+
+ <firstterm>LRU chain</firstterm>
+
+ ) of all used blocks. When a block is accessed, it is placed at
+ the end of the queue. When blocks need to be replaced, blocks at
+ the beginning of the queue are the least recently used and
+ become the first candidates for eviction.
</para>
<section id="shared-key-cache">
@@ -6067,7 +6072,7 @@
<listitem>
<para>
- A buffer being updated causes threads that need to use it
+ A buffer being updated causes threads that need to use it
to wait until the update is complete.
</para>
</listitem>
@@ -6160,8 +6165,9 @@
</programlisting>
<para>
- Note that you cannot destroy the default key cache. Any
+ Note that you cannot destroy the default key cache. Any
attempt to do this will be ignored:
+ </para>
<programlisting>
mysql> <userinput>set global key_buffer_size = 0;</userinput>
@@ -6173,7 +6179,6 @@
| key_buffer_size | 8384512 |
+-----------------+---------+
</programlisting>
- </para>
<para>
Key cache variables are structured system variables that have
@@ -6353,10 +6358,10 @@
The threshold value prescribes that, for a key cache
containing <replaceable>N</replaceable> blocks, the block at
the beginning of the hot sub-chain not accessed within the
- last <literal><replaceable>N</replaceable> *
- key_cache_age_threshold / 100</literal> hits is to be moved to
- the beginning of the warm sub-chain. It then becomes the first
- candidate for eviction, because blocks for replacement always
+ last <literal><replaceable>N</replaceable> *
+ key_cache_age_threshold / 100</literal> hits is to be moved to
+ the beginning of the warm sub-chain. It then becomes the first
+ candidate for eviction, because blocks for replacement always
are taken from the beginning of the warm sub-chain.
</para>
@@ -6399,7 +6404,7 @@
Without preloading, the blocks are still placed into the key
cache as needed by queries. Although the blocks will stay in
the cache, because there are enough buffers for all of them,
- they are fetched from disk in random order, and not
+ they are fetched from disk in random order, and not
sequentially.
</para>
@@ -6847,7 +6852,7 @@
<listitem>
<para>
Use the <option>--skip-external-locking</option> MySQL
- option to avoid external locking. This option is turned on
+ option to avoid external locking. This option is turned on
by default as of MySQL 4.0. Before that, it is on by default
when compiling with MIT-pthreads, because
<literal>flock()</literal> is not fully supported by
@@ -7117,10 +7122,10 @@
</programlisting>
<para>
- If you are performing <literal>GROUP BY</literal> or
- <literal>ORDER BY</literal> operations on tables that are much
- larger than your available memory, you should increase the value
- of <literal>read_rnd_buffer_size</literal> to speed up the
+ If you are performing <literal>GROUP BY</literal> or
+ <literal>ORDER BY</literal> operations on tables that are much
+ larger than your available memory, you should increase the value
+ of <literal>read_rnd_buffer_size</literal> to speed up the
reading of rows following sorting operations.
</para>
@@ -7205,22 +7210,22 @@
On Linux, you get the fastest server when compiling with
<command>pgcc</command> and <option>-O3</option>. You need about
200MB memory to compile <filename>sql_yacc.cc</filename> with
- these options, because <command>gcc</command> or
- <command>pgcc</command> needs a large amount of memory to make
- all functions inline. You should also set
+ these options, because <command>gcc</command> or
+ <command>pgcc</command> needs a large amount of memory to make
+ all functions inline. You should also set
<literal>CXX=gcc</literal> when configuring MySQL to avoid
inclusion of the <literal>libstdc++</literal> library, which is
not needed. Note that with some versions of
- <command>pgcc</command>, the resulting executable runs only on
+ <command>pgcc</command>, the resulting executable runs only on
true Pentium processors, even if you use the compiler option
- indicating that you want it to work on all x586-type processors
+ indicating that you want it to work on all x586-type processors
(such as AMD).
</para>
<para>
- Simply by using a better compiler and better compiler options,
- you can obtain a 10-30% speed increase in your applications.
- This is particularly important if you compile the MySQL server
+ Simply by using a better compiler and better compiler options,
+ you can obtain a 10-30% speed increase in your applications.
+ This is particularly important if you compile the MySQL server
yourself.
</para>
@@ -7526,7 +7531,7 @@
<listitem>
<para>
- For each <literal>MyISAM</literal> or
+ For each <literal>MyISAM</literal> or
<literal>ISAM</literal> table that is opened, the index file
is opened once and the data file is opened once for each
concurrently running thread. For each concurrent thread, a
@@ -7717,16 +7722,14 @@
better, assuming that the disk is not used for other
purposes as well. See <xref linkend="symbolic-links"/>.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>striping</primary>
- <secondary>defined</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>striping</primary>
+ <secondary>defined</secondary>
+ </indexterm>
+
<para>
Striping
</para>
@@ -7734,14 +7737,14 @@
<para>
Striping means that you have many disks and put the first
block on the first disk, the second block on the second
- disk, and the <replaceable>N</replaceable>th block on the
- (<literal><replaceable>N</replaceable>
- mod number_of_disks</literal>) disk, and so on. This means if your normal data size is
- less than the stripe size (or perfectly aligned), you get
- much better performance. Striping is very dependent on the
- operating system and the stripe size, so benchmark your
- application with different stripe sizes. See
- <xref linkend="custom-benchmarks"/>.
+ disk, and the <replaceable>N</replaceable>th block on the
+ (<literal><replaceable>N</replaceable> mod
+ number_of_disks</literal>) disk, and so on. This means if
+ your normal data size is less than the stripe size (or
+ perfectly aligned), you get much better performance.
+ Striping is very dependent on the operating system and the
+ stripe size, so benchmark your application with different
+ stripe sizes. See <xref linkend="custom-benchmarks"/>.
</para>
<para>
@@ -7810,11 +7813,11 @@
</para>
<para>
- If you do not need to know when files were last accessed (which
- is not really useful on a database server), you can mount your
- filesystems with the <option>-o noatime</option> option. That
- skips updates to the last access time in inodes on the
- filesystem, which avoids some disk seeks.
+ If you do not need to know when files were last accessed
+ (which is not really useful on a database server), you can
+ mount your filesystems with the <option>-o noatime</option>
+ option. That skips updates to the last access time in inodes
+ on the filesystem, which avoids some disk seeks.
</para>
<para>
@@ -8070,15 +8073,15 @@
</itemizedlist>
<para>
- <literal>SHOW CREATE TABLE</literal> does not report if a table
- has symbolic links prior to MySQL 4.0.15. This is also true
- for <command>mysqldump</command>, which uses <literal>SHOW
- CREATE TABLE</literal> to generate <literal>CREATE
- TABLE</literal> statements.
+ <literal>SHOW CREATE TABLE</literal> does not report if a
+ table has symbolic links prior to MySQL 4.0.15. This is also
+ true for <command>mysqldump</command>, which uses
+ <literal>SHOW CREATE TABLE</literal> to generate
+ <literal>CREATE TABLE</literal> statements.
</para>
<para>
- Table symlink operations that are not supported up through
+ Table symlink operations that are not supported up through
MySQL 4.1:
</para>
@@ -8207,10 +8210,10 @@
</programlisting>
<para>
- On Windows, you can make a symbolic link to a MySQL database
- by creating a file in the data directory that contains the
+ On Windows, you can make a symbolic link to a MySQL database
+ by creating a file in the data directory that contains the
path to the destination directory. The file should be named
- <filename><replaceable>db_name</replaceable>.sym</filename>,
+ <filename><replaceable>db_name</replaceable>.sym</filename>,
where <replaceable>db_name</replaceable> is the database name.
</para>
@@ -8248,8 +8251,8 @@
<para>
After that, all tables created in the database
<literal>foo</literal> are created in
- <filename>D:\data\foo</filename>. <emphasis>Note that the
- symbolic link is not used if a directory with the same name as
+ <filename>D:\data\foo</filename>. <emphasis>Note that the
+ symbolic link is not used if a directory with the same name as
the database exists in the MySQL data directory</emphasis>.
</para>
--- 1.8/refman/mysql-optimization.xml 2005-08-10 05:43:11 -05:00
+++ 1.10/refman/mysql-optimization.xml 2005-08-15 14:12:17 -05:00
@@ -917,16 +917,16 @@
<itemizedlist>
- <indexterm type="concept">
- <primary>system table</primary>
- </indexterm>
+ <listitem>
+ <indexterm type="concept">
+ <primary>system table</primary>
+ </indexterm>
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>system</secondary>
- </indexterm>
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>system</secondary>
+ </indexterm>
- <listitem>
<para>
<literal>system</literal>
</para>
@@ -935,20 +935,18 @@
The table has only one row (= system table). This is a
special case of the <literal>const</literal> join type.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>constant table</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>constant</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>constant table</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>constant</secondary>
+ </indexterm>
+
<para>
<literal>const</literal>
</para>
@@ -971,14 +969,12 @@
<literal>const</literal> table:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1010,7 +1006,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>;
@@ -1019,7 +1014,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1039,9 +1033,7 @@
a good join type.
</para>
- <para>
<!-- Note: The "or <=>" applies only to ref, not to eq_ref. -->
- </para>
<para>
<literal>ref</literal> can be used for indexed columns
@@ -1055,7 +1047,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
@@ -1066,7 +1057,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1088,12 +1078,10 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>
WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
</programlisting>
- </para>
<para>
See <xref linkend="is-null-optimization"/>.
@@ -1124,11 +1112,13 @@
<para>
This type replaces <literal>ref</literal> for some
<literal>IN</literal> subqueries of the following form:
+ </para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>primary_key</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
+ <para>
<literal>unique_subquery</literal> is just an index
lookup function that replaces the subquery completely
for better efficiency.
@@ -1147,11 +1137,9 @@
non-unique indexes in subqueries of the following form:
</para>
- <para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>key_column</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1180,7 +1168,6 @@
operators:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_column</replaceable> = 10;
@@ -1194,7 +1181,6 @@
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1319,16 +1305,13 @@
constants are used with the <literal>key</literal> to select
rows from the table.
</para>
-
- <para>
-<!-- TODO: we don't seem to explain what ref values of "const", NULL, or -->
- </para>
-
- <para>
-<!-- @var{tbl_name.col_name} mean. -->
- </para>
</listitem>
+<!--
+ TODO: We do not seem to explain what ref values of "const", NULL,
+ or @var{tbl_name.col_name} mean.
+-->
+
<listitem>
<para>
<literal>rows</literal>
@@ -1382,12 +1365,10 @@
optimized this way:
</para>
- <para>
<programlisting>
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
</programlisting>
- </para>
<para>
Assume that <literal>t2.id</literal> is defined as
@@ -2001,35 +1982,35 @@
<listitem>
<para>
Removal of unnecessary parentheses:
+ </para>
<programlisting>
((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant folding:
+ </para>
<programlisting>
(a<b AND b=c) AND a=5
-> b>5 AND b=c AND a=5
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant condition removal (needed because of constant
folding):
+ </para>
<programlisting>
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6
</programlisting>
- </para>
</listitem>
<listitem>
@@ -4557,17 +4538,16 @@
important for you, you should consider using the table in
ways that avoid deleting rows. Another possibility is to run
<literal>OPTIMIZE TABLE</literal> after you have deleted a
- lot of rows.
- See <xref linkend="myisam-storage-engine"/>.
+ lot of rows. See <xref linkend="myisam-storage-engine"/>.
</para>
</listitem>
<listitem>
<para>
- To fix any compression issues that may have occurred
- with <literal>ARCHIVE</literal> tables
- you can always do an <literal>OPTIMIZE TABLE</literal>.
- See <xref linkend="archive-storage-engine"/>.
+ To fix any compression issues that may have occurred with
+ <literal>ARCHIVE</literal> tables you can always do an
+ <literal>OPTIMIZE TABLE</literal>. See
+ <xref linkend="archive-storage-engine"/>.
</para>
</listitem>
@@ -6153,12 +6133,12 @@
<para>
The following <literal>SELECT</literal> statements do not use
indexes:
+ </para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE '%Patrick%';
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE <replaceable>other_col</replaceable>;
</programlisting>
- </para>
<para>
In the first statement, the <literal>LIKE</literal> value begins
@@ -6201,6 +6181,7 @@
<para>
The following <literal>WHERE</literal> clauses use indexes:
+ </para>
<programlisting>
... WHERE <replaceable>index_part1</replaceable>=1 AND <replaceable>index_part2</replaceable>=2 AND <replaceable>other_column</replaceable>=3
@@ -6211,7 +6192,6 @@
/* Can use index on <replaceable>index1</replaceable> but not on <replaceable>index2</replaceable> or <replaceable>index3</replaceable> */
... WHERE <replaceable>index1</replaceable>=1 AND <replaceable>index2</replaceable>=2 OR <replaceable>index1</replaceable>=3 AND <replaceable>index3</replaceable>=3;
</programlisting>
- </para>
<para>
These <literal>WHERE</literal> clauses do
@@ -6551,6 +6531,7 @@
<para>
Note that you cannot destroy the default key cache. An attempt
to do this will be ignored:
+ </para>
<programlisting>
mysql> <userinput>set global key_buffer_size = 0;</userinput>
@@ -6562,7 +6543,6 @@
| key_buffer_size | 8384512 |
+-----------------+---------+
</programlisting>
- </para>
<para>
Key cache variables are structured system variables that have
@@ -8190,16 +8170,14 @@
better, assuming that the disk is not used for other
purposes as well. See <xref linkend="symbolic-links"/>.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>striping</primary>
- <secondary>defined</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>striping</primary>
+ <secondary>defined</secondary>
+ </indexterm>
+
<para>
Striping
</para>
--- 1.4/refman-5.0/mysql-optimization.xml 2005-08-10 05:44:16 -05:00
+++ 1.6/refman-5.0/mysql-optimization.xml 2005-08-15 14:12:16 -05:00
@@ -925,16 +925,16 @@
<itemizedlist>
- <indexterm type="concept">
- <primary>system table</primary>
- </indexterm>
+ <listitem>
+ <indexterm type="concept">
+ <primary>system table</primary>
+ </indexterm>
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>system</secondary>
- </indexterm>
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>system</secondary>
+ </indexterm>
- <listitem>
<para>
<literal>system</literal>
</para>
@@ -943,20 +943,18 @@
The table has only one row (= system table). This is a
special case of the <literal>const</literal> join type.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>constant table</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>constant</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>constant table</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>constant</secondary>
+ </indexterm>
+
<para>
<literal>const</literal>
</para>
@@ -979,14 +977,12 @@
<literal>const</literal> table:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1018,7 +1014,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>;
@@ -1027,7 +1022,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1061,7 +1055,6 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
@@ -1072,7 +1065,6 @@
WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1094,12 +1086,10 @@
<replaceable>ref_table</replaceable>:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>ref_table</replaceable>
WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
</programlisting>
- </para>
<para>
See <xref linkend="is-null-optimization"/>.
@@ -1130,11 +1120,13 @@
<para>
This type replaces <literal>ref</literal> for some
<literal>IN</literal> subqueries of the following form:
+ </para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>primary_key</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
+ <para>
<literal>unique_subquery</literal> is just an index
lookup function that replaces the subquery completely
for better efficiency.
@@ -1153,11 +1145,9 @@
non-unique indexes in subqueries of the following form:
</para>
- <para>
<programlisting>
<replaceable>value</replaceable> IN (SELECT <replaceable>key_column</replaceable> FROM <replaceable>single_table</replaceable> WHERE <replaceable>some_expr</replaceable>)
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1186,7 +1176,6 @@
operators:
</para>
- <para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_column</replaceable> = 10;
@@ -1200,7 +1189,6 @@
SELECT * FROM <replaceable>tbl_name</replaceable>
WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
</programlisting>
- </para>
</listitem>
<listitem>
@@ -1328,7 +1316,7 @@
</listitem>
<!--
- TODO: We don't seem to explain what ref values of "const", NULL,
+ TODO: We do not seem to explain what ref values of "const", NULL,
or <replaceable>tbl_name.col_name</replaceable> mean.
-->
@@ -1385,12 +1373,10 @@
optimized this way:
</para>
- <para>
<programlisting>
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
</programlisting>
- </para>
<para>
Assume that <literal>t2.id</literal> is defined as
@@ -2004,35 +1990,35 @@
<listitem>
<para>
Removal of unnecessary parentheses:
+ </para>
<programlisting>
((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant folding:
+ </para>
<programlisting>
(a<b AND b=c) AND a=5
-> b>5 AND b=c AND a=5
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Constant condition removal (needed because of constant
folding):
+ </para>
<programlisting>
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6
</programlisting>
- </para>
</listitem>
<listitem>
@@ -3536,40 +3522,42 @@
the columns required for the query as well. This avoids reading
the rows twice. The <literal>filesort</literal> algorithm works
like this:
+ </para>
- <orderedlist>
+ <orderedlist>
- <listitem>
- <para>
- Read the rows that match the <literal>WHERE</literal>
- clause, as before.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Read the rows that match the <literal>WHERE</literal>
+ clause, as before.
+ </para>
+ </listitem>
- <listitem>
- <para>
- For each row, record a tuple of values consisting of the
- sort key value and row position, and also the columns
- required for the query.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ For each row, record a tuple of values consisting of the
+ sort key value and row position, and also the columns
+ required for the query.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Sort the tuples by sort key value
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Sort the tuples by sort key value
+ </para>
+ </listitem>
- <listitem>
- <para>
- Retrieve the rows in sorted order, but read the required
- columns directly from the sorted tuples rather than by
- accessing the table a second time.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Retrieve the rows in sorted order, but read the required
+ columns directly from the sorted tuples rather than by
+ accessing the table a second time.
+ </para>
+ </listitem>
- </orderedlist>
+ </orderedlist>
+ <para>
This algorithm represents an improvement over that used in some
older versions of MySQL.
</para>
@@ -4507,17 +4495,16 @@
important for you, you should consider using the table in
ways that avoid deleting rows. Another possibility is to run
<literal>OPTIMIZE TABLE</literal> after you have deleted a
- lot of rows.
- See <xref linkend="myisam-storage-engine"/>.
+ lot of rows. See <xref linkend="myisam-storage-engine"/>.
</para>
</listitem>
<listitem>
<para>
- To fix any compression issues that may have occurred
- with <literal>ARCHIVE</literal> tables
- you can always do an <literal>OPTIMIZE TABLE</literal>.
- See <xref linkend="archive-storage-engine"/>.
+ To fix any compression issues that may have occurred with
+ <literal>ARCHIVE</literal> tables you can always do an
+ <literal>OPTIMIZE TABLE</literal>. See
+ <xref linkend="archive-storage-engine"/>.
</para>
</listitem>
@@ -5154,42 +5141,42 @@
<para>
Options other than row-level or page-level locking:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- Versioning (such as that used in MySQL for concurrent
- inserts) where it is possible to have one writer at the
- same time as many readers. This means that the database or
- table supports different views for the data depending on
- when access begins. Other common terms for this are
- <quote>time travel</quote>, <quote>copy on write</quote>,
- or <quote>copy on demand</quote>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Versioning (such as that used in MySQL for concurrent
+ inserts) where it is possible to have one writer at the same
+ time as many readers. This means that the database or table
+ supports different views for the data depending on when
+ access begins. Other common terms for this are <quote>time
+ travel</quote>, <quote>copy on write</quote>, or <quote>copy
+ on demand</quote>.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Copy on demand is in many cases superior to page-level or
- row-level locking. However, in the worst case, it can use
- much more memory than using normal locks.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Copy on demand is in many cases superior to page-level or
+ row-level locking. However, in the worst case, it can use
+ much more memory than using normal locks.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Instead of using row-level locks, you can employ
- application-level locks, such as
- <literal>GET_LOCK()</literal> and
- <literal>RELEASE_LOCK()</literal> in MySQL. These are
- advisory locks, so they work only in well-behaved
- applications.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Instead of using row-level locks, you can employ
+ application-level locks, such as
+ <literal>GET_LOCK()</literal> and
+ <literal>RELEASE_LOCK()</literal> in MySQL. These are
+ advisory locks, so they work only in well-behaved
+ applications.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
</section>
@@ -6133,12 +6120,12 @@
<para>
The following <literal>SELECT</literal> statements do
<emphasis>not</emphasis> use indexes:
+ </para>
<programlisting>
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE '%Patrick%';
SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> LIKE <replaceable>other_col</replaceable>;
</programlisting>
- </para>
<para>
In the first statement, the <literal>LIKE</literal> value begins
@@ -6185,6 +6172,7 @@
<para>
The following <literal>WHERE</literal> clauses use indexes:
+ </para>
<programlisting>
... WHERE <replaceable>index_part1</replaceable>=1 AND <replaceable>index_part2</replaceable>=2 AND <replaceable>other_column</replaceable>=3
@@ -6195,7 +6183,6 @@
/* Can use index on <replaceable>index1</replaceable> but not on <replaceable>index2</replaceable> or <replaceable>index3</replaceable> */
... WHERE <replaceable>index1</replaceable>=1 AND <replaceable>index2</replaceable>=2 OR <replaceable>index1</replaceable>=3 AND <replaceable>index3</replaceable>=3;
</programlisting>
- </para>
<para>
These <literal>WHERE</literal> clauses do
@@ -6523,6 +6510,7 @@
<para>
Note that you cannot destroy the default key cache. An attempt
to do this will be ignored:
+ </para>
<programlisting>
mysql> <userinput>set global key_buffer_size = 0;</userinput>
@@ -6534,7 +6522,6 @@
| key_buffer_size | 8384512 |
+-----------------+---------+
</programlisting>
- </para>
<para>
Key cache variables are structured system variables that have
@@ -8234,16 +8221,14 @@
better, assuming that the disk is not used for other
purposes as well. See <xref linkend="symbolic-links"/>.
</para>
-
- <para>
- <indexterm type="concept">
- <primary>striping</primary>
- <secondary>defined</secondary>
- </indexterm>
- </para>
</listitem>
<listitem>
+ <indexterm type="concept">
+ <primary>striping</primary>
+ <secondary>defined</secondary>
+ </indexterm>
+
<para>
Striping
</para>
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
|
| |
|
| |
|
| |
|
Index ‹ mysql |
- Next
- 1
- Differences between MySQL 5 and MaxDB?Have been using MySQL on an infrequent basis, mostly on web databases.
Now the MySQL site is pushing both products.
Both now support stored procedures and triggers.
So exactly what are the major differences between MySQL and MaxDB? I have
not seen a "which version is right for you" document or web site. The MaxDB
site link
http://dev.mysql.com/downloads/maxdb/7.6.00.html
does not seem to say much. I find only the defining term "enterprise"
proferred.
How do they compare?
TIA
~ Duane Phillips.
- 2
- Newbie Question: Create statically linked executableOn Wed, May 25, 2005 at 08:56:39PM +0800, Willy K' wrote:
> g++ -I/usr/include/mysql++ -I/usr/include/mysql -02 -c
> application.cpp
> g++ -I/usr/include/mysql++ -I/usr/include/mysql -02 -c
> util.cpp
> g++ -Wall -02 -o StaticExe application.o util.o -static -
> lmysqlpp -lmysqlclient
> it gives back a error of:
> /usr/bin/ld: cannot find -lmysqlclient
> collect2: ld return 1 exit status
Static linking requires that you have .a files for all libraries you want
to link statically. Apparently you don't have a static version of the
mysql C API library on your system. (i.e. libmysqlclient.a, not
libmysqlclient.so)
- Chris
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=email***@***.com
- 3
- bk commit into 5.0 tree (jimw:1.2034)Below is the list of changes that have just been committed into a local
5.0 repository of jimw. When jimw does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.2034 05/12/01 11:11:03 email***@***.com +5 -0
Enable key lengths of up to 3K on 32-bit platforms.
sql/unireg.h
1.42 05/12/01 11:11:00 email***@***.com +1 -5
Allow key length of 3K even on 32-bit platforms
mysql-test/t/innodb.test
1.117 05/12/01 11:11:00 email***@***.com +19 -0
Add simple test that large keys are allowed
mysql-test/t/bdb.test
1.49 05/12/01 11:11:00 email***@***.com +19 -0
Add simple test that large keys are allowed
mysql-test/r/innodb.result
1.146 05/12/01 11:10:59 email***@***.com +14 -0
Add new results
mysql-test/r/bdb.result
1.47 05/12/01 11:10:59 email***@***.com +14 -0
Add new results
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jimw
# Host: rama.(none)
# Root: /home/jimw/my/mysql-5.0-keysize
--- 1.41/sql/unireg.h 2005-11-23 16:36:25 -08:00
+++ 1.42/sql/unireg.h 2005-12-01 11:11:00 -08:00
@@ -50,11 +50,7 @@
#define MAX_SYS_VAR_LENGTH 32
#define MAX_KEY 64 /* Max used keys */
#define MAX_REF_PARTS 16 /* Max parts used as ref */
-#if SIZEOF_CHARP > 4
-#define MAX_KEY_LENGTH 3072 /* max possible key, if 64 bits */
-#else
-#define MAX_KEY_LENGTH 1024 /* max possible key, if 32 bits */
-#endif
+#define MAX_KEY_LENGTH 3072 /* max possible key */
#if SIZEOF_OFF_T > 4
#define MAX_REFLENGTH 8 /* Max length for record ref */
#else
--- 1.145/mysql-test/r/innodb.result 2005-10-19 09:06:22 -07:00
+++ 1.146/mysql-test/r/innodb.result 2005-12-01 11:10:59 -08:00
@@ -2772,3 +2772,17 @@
drop table t1;
drop table t2;
commit;
+create table t1 (a varchar(255) character set utf8,
+b varchar(255) character set utf8,
+c varchar(255) character set utf8,
+d varchar(255) character set utf8,
+key (a,b,c,d)) engine=innodb;
+drop table t1;
+create table t1 (a varchar(255) character set utf8,
+b varchar(255) character set utf8,
+c varchar(255) character set utf8,
+d varchar(255) character set utf8,
+e varchar(255) character set utf8,
+key (a,b,c,d,e)) engine=innodb;
+ERROR 42000: Specified key was too long; max key length is 3072 bytes
+End of 5.0 tests
--- 1.116/mysql-test/t/innodb.test 2005-10-19 09:06:22 -07:00
+++ 1.117/mysql-test/t/innodb.test 2005-12-01 11:11:00 -08:00
@@ -1751,3 +1751,22 @@
drop table t1;
drop table t2;
commit;
+
+#
+# Test that we can create a large (>1K) key
+#
+create table t1 (a varchar(255) character set utf8,
+ b varchar(255) character set utf8,
+ c varchar(255) character set utf8,
+ d varchar(255) character set utf8,
+ key (a,b,c,d)) engine=innodb;
+drop table t1;
+--error ER_TOO_LONG_KEY
+create table t1 (a varchar(255) character set utf8,
+ b varchar(255) character set utf8,
+ c varchar(255) character set utf8,
+ d varchar(255) character set utf8,
+ e varchar(255) character set utf8,
+ key (a,b,c,d,e)) engine=innodb;
+
+--echo End of 5.0 tests
--- 1.46/mysql-test/r/bdb.result 2005-11-02 06:28:55 -08:00
+++ 1.47/mysql-test/r/bdb.result 2005-12-01 11:10:59 -08:00
@@ -1891,3 +1891,17 @@
) ENGINE=BerkeleyDB DEFAULT CHARSET=latin1
drop table t1;
set storage_engine=MyISAM;
+create table t1 (a varchar(255) character set utf8,
+b varchar(255) character set utf8,
+c varchar(255) character set utf8,
+d varchar(255) character set utf8,
+key (a,b,c,d)) engine=bdb;
+drop table t1;
+create table t1 (a varchar(255) character set utf8,
+b varchar(255) character set utf8,
+c varchar(255) character set utf8,
+d varchar(255) character set utf8,
+e varchar(255) character set utf8,
+key (a,b,c,d,e)) engine=bdb;
+ERROR 42000: Specified key was too long; max key length is 3072 bytes
+End of 5.0 tests
--- 1.48/mysql-test/t/bdb.test 2005-11-02 06:28:55 -08:00
+++ 1.49/mysql-test/t/bdb.test 2005-12-01 11:11:00 -08:00
@@ -974,3 +974,22 @@
# End varchar test
eval set storage_engine=$default;
+
+#
+# Test that we can create a large key
+#
+create table t1 (a varchar(255) character set utf8,
+ b varchar(255) character set utf8,
+ c varchar(255) character set utf8,
+ d varchar(255) character set utf8,
+ key (a,b,c,d)) engine=bdb;
+drop table t1;
+--error ER_TOO_LONG_KEY
+create table t1 (a varchar(255) character set utf8,
+ b varchar(255) character set utf8,
+ c varchar(255) character set utf8,
+ d varchar(255) character set utf8,
+ e varchar(255) character set utf8,
+ key (a,b,c,d,e)) engine=bdb;
+
+--echo End of 5.0 tests
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 4
- select statement question-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all. I hope this is the right place to ask this.
I have two tables, A and B. Each of these tables has a column with
integers. The column in table A is C and the one in B is D.
I need a select statement that will return all records whose C value is not
in any row in D.
for example:
C =
1
2
3
4
5
6
7
8
11
D =
2
4
6
8
10
and the statement would return:
1
3
5
7
11
Probably an easy question for those of you more experienced but I have no
clew.
Thanks in advance.
Sincerely
Aaron Cannon
- --
Skype: cannona
MSN/Windows Messenger: email***@***.com (don't send email to the hotmail
address.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
Comment: Key available from all major key servers.
iD8DBQFFnBbLI7J99hVZuJcRAiF3AJ4mR4UjLa0sG+hIDbErj7LvuzfU4wCggEDh
DtnfmVsHL84me4qVw/mA4s8=
=l2gE
-----END PGP SIGNATURE-----
- 5
- bk commit - mysqldoc@docsrva tree (jon:1.2885)Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2885 05/06/26 11:27:19 email***@***.com +3 -0
column-types.xml: storage-requirements: Fixed typo.
Sync refman-4.1 & refman-5.0 to refman.
refman/column-types.xml
1.6 05/06/26 11:27:18 email***@***.com +1 -1
storage-requirements: Fixed typo.
refman-5.0/column-types.xml
1.6 05/06/26 11:27:18 email***@***.com +1 -1
storage-requirements: Fixed typo.
Sync to refman.
refman-4.1/column-types.xml
1.6 05/06/26 11:27:17 email***@***.com +1 -1
storage-requirements: Fixed typo.
Sync to refman.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.site
# Root: /home/jon/bk/mysqldoc
--- 1.5/refman-4.1/column-types.xml 2005-06-23 17:10:49 +10:00
+++ 1.6/refman-4.1/column-types.xml 2005-06-26 11:27:17 +10:00
@@ -5163,7 +5163,7 @@
<para>
As of MySQL 5.0.3, the <literal>NDBCLUSTER</literal> engine supports
only fixed-width columns. This means that a
- <literal>VARCHAR</literal> column from a table in a MySQL CLuster
+ <literal>VARCHAR</literal> column from a table in a MySQL Cluster
will behave almost as if it were of type <literal>CHAR</literal>
(except that each record still has one extra byte overhead). For
example, in a Cluster table, <emphasis>each</emphasis> record in a
--- 1.5/refman-5.0/column-types.xml 2005-06-23 17:10:51 +10:00
+++ 1.6/refman-5.0/column-types.xml 2005-06-26 11:27:18 +10:00
@@ -5163,7 +5163,7 @@
<para>
As of MySQL 5.0.3, the <literal>NDBCLUSTER</literal> engine supports
only fixed-width columns. This means that a
- <literal>VARCHAR</literal> column from a table in a MySQL CLuster
+ <literal>VARCHAR</literal> column from a table in a MySQL Cluster
will behave almost as if it were of type <literal>CHAR</literal>
(except that each record still has one extra byte overhead). For
example, in a Cluster table, <emphasis>each</emphasis> record in a
--- 1.5/refman/column-types.xml 2005-06-23 17:09:52 +10:00
+++ 1.6/refman/column-types.xml 2005-06-26 11:27:18 +10:00
@@ -5163,7 +5163,7 @@
<para>
As of MySQL 5.0.3, the <literal>NDBCLUSTER</literal> engine supports
only fixed-width columns. This means that a
- <literal>VARCHAR</literal> column from a table in a MySQL CLuster
+ <literal>VARCHAR</literal> column from a table in a MySQL Cluster
will behave almost as if it were of type <literal>CHAR</literal>
(except that each record still has one extra byte overhead). For
example, in a Cluster table, <emphasis>each</emphasis> record in a
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 6
- Period loss of database connectionsI've been having problems with our two java servers periodically being
unable to maintain connections to our MySQL database. My code uses the
Jakarta DBCP library for connection pooling and its a web-based app
running under TomCat (mostly XML-RPC work with a little JSP). And, I'm
using the 3.0.9 release of Connector/J with MySQL 4.0.14.
The trouble seems to start with a communication link failure
(java.net.SocketTimeoutException; underlying case: Read timed out).
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at
java.io.BufferedInputStream.read(BufferedInputStream.java:201)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1399)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1775)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1020)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1109)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2030)
at
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:
1563)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(Delegat
ingPreparedStatement.java:205)
at com.techtracker.mapping.TTHome.find(TTHome.java:289)
These exceptions continue to appear in the logs (to the extent of the
thread pool, I'm guessing). Now, the thread pool should be testing the
connection "on borrow", so I'm guessing the connections are okay when
my code gains controls and they die somewhere there.
Once the above exceptions cease, the logs begin reporting the
reconnection attempts by the connection pool in trying to replace the
dead connections (I think). At this point, I see 'java.sql.Exception:
Server configuration denies access to data source'. Of course, I get
this error from the pool driver manager, so I can't be sure what the
MySQL driver might be saying. Anyway, these errors persist and java
never appears to be able to create another connection to the database.
But, if you restart the VM, all is well.
The servers are service requests and interacting with the database for
anywhere between one and three days before these failures occur. And,
when they occur, they happen to both servers simultaneously. The
database, itself, appears fine (although, I admit that we usually don't
detect the problem until the java servers have been down for a while).
Does anyone have any clues that could point me to the problem or to
help me diagnosis this problem. Any advice would be much appreciated as
I've tried all the tricks I know (besides diving into the Jakarta code
to see if its there [I'm sure Mark's code is perfect! :-) ]).
Ken
--
MySQL Java Mailing List
For list archives: http://lists.mysql.com/java
To unsubscribe: http://lists.mysql.com/java?unsub=email***@***.com
- 7
- Privileges problemsI'm having trouble with Mysql privileges. If I type mysql from my
default account, 'markus', I get the access denied error 1045 for user
'markus'@'localhost' (using password:YES)
To my knowledge, I don't have a password on that account. I run su and
run mysql -u root mysql to look at the user table. There I have an
account for 'markus'@'localhost' and 'markus'@'%'. To make sure these
accounts are properly privileged, I delete them from the table and then
run 'grant all privileges on *.* to 'markus'@'localhost' with grant
option;. I also run it for '%'. I try running mysql from 'markus'
again, and it fails.
What am I missing regarding the privileges system?
Thanks
- 8
- bk commit into 5.1-ndb tree (joreland:1.1810)Below is the list of changes that have just been committed into a local
5.1-ndb repository of jonas. When jonas does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.1810 05/03/30 19:29:59 email***@***.com +3 -0
wl1866 - ndb diskdata
Fix closing of transaction in UtilTransactions
ndb/test/src/UtilTransactions.cpp
1.18 05/03/30 19:29:56 email***@***.com +68 -63
Fix closing of transaction in UtilTransactions
ndb/test/src/HugoOperations.cpp
1.18 05/03/30 19:29:56 email***@***.com +1 -5
Fix closing of transaction in UtilTransactions
ndb/test/include/UtilTransactions.hpp
1.7 05/03/30 19:29:56 email***@***.com +2 -0
Fix closing of transaction in UtilTransactions
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: joreland
# Host: eel.hemma.oreland.se
# Root: /home/jonas/src/mysql-5.1-ndb-dd
--- 1.6/ndb/test/include/UtilTransactions.hpp Mon Mar 7 18:47:37 2005
+++ 1.7/ndb/test/include/UtilTransactions.hpp Wed Mar 30 19:29:56 2005
@@ -124,6 +124,8 @@
NdbOperation* getOperation(NdbConnection*,
NdbOperation::OperationType);
NdbScanOperation* getScanOperation(NdbConnection*);
+
+ void closeTransaction(Ndb* pNdb);
};
#endif
--- 1.17/ndb/test/src/HugoOperations.cpp Thu Feb 3 17:04:25 2005
+++ 1.18/ndb/test/src/HugoOperations.cpp Wed Mar 30 19:29:56 2005
@@ -54,11 +54,7 @@
int HugoOperations::closeTransaction(Ndb* pNdb){
- if (pTrans != NULL){
- pNdb->closeTransaction(pTrans);
- pTrans = NULL;
- }
- pTrans = NULL;
+ UtilTransactions::closeTransaction(pNdb);
m_result_sets.clear();
m_executed_result_sets.clear();
--- 1.17/ndb/test/src/UtilTransactions.cpp Mon Mar 7 18:47:38 2005
+++ 1.18/ndb/test/src/UtilTransactions.cpp Wed Mar 30 19:29:56 2005
@@ -109,7 +109,7 @@
err = pTrans->getNdbError();
if(err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
par = 1;
goto restart;
@@ -126,7 +126,7 @@
err = pTrans->getNdbError();
if(err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
continue;
}
@@ -150,7 +150,7 @@
if(check == -1){
if(err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
par = 1;
goto restart;
@@ -162,20 +162,20 @@
err = pTrans->getNdbError();
if(err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
par = 1;
goto restart;
}
goto failed;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_OK;
}
return NDBT_FAILED;
failed:
- if(pTrans != 0) pNdb->closeTransaction(pTrans);
+ if(pTrans != 0) closeTransaction(pNdb);
ERR(err);
return (err.code != 0 ? err.code : NDBT_FAILED);
}
@@ -219,20 +219,20 @@
pOp = pTrans->getNdbScanOperation(tab.getName());
if (pOp == NULL) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
if( pOp->readTuples(NdbScanOperation::LM_Read, parallelism) ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
check = pOp->interpret_exit_ok();
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -241,7 +241,7 @@
if ((row.attributeStore(a) =
pOp->getValue(tab.getColumn(a)->getName())) == 0) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -249,7 +249,7 @@
check = pTrans->execute(NoCommit);
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -258,7 +258,7 @@
do {
insertedRows++;
if (addRowToInsert(pNdb, pTrans, row, destName) != 0){
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
} while((eof = pOp->nextResult(false)) == 0);
@@ -268,7 +268,7 @@
if( check == -1 ) {
const NdbError err = pTrans->getNdbError();
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -277,7 +277,7 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
// If error = 488 there should be no limit on number of retry attempts
if (err.code != 488)
@@ -285,11 +285,11 @@
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
g_info << insertedRows << " rows copied" << endl;
@@ -375,7 +375,7 @@
pOp = getScanOperation(pTrans);
if (pOp == NULL) {
const NdbError err = pNdb->getNdbError();
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
if (err.status == NdbError::TemporaryError){
ERR(err);
@@ -389,14 +389,14 @@
if( pOp->readTuples(lm, 0, parallelism) ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
check = pOp->interpret_exit_ok();
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -408,7 +408,7 @@
if ((row.attributeStore(attrib_list[a]) =
pOp->getValue(tab.getColumn(attrib_list[a])->getName())) == 0) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -421,13 +421,13 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -447,17 +447,17 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
g_info << rows << " rows have been read" << endl;
if (records != 0 && rows != records){
g_info << "Check expected number of records failed" << endl
@@ -496,13 +496,13 @@
pOp = getScanOperation(pTrans);
if (pOp == NULL) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
if( pOp->readTuples(lm) ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -515,7 +515,7 @@
check = pOp->interpret_exit_ok();
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -524,7 +524,7 @@
check = pTrans->execute(NoCommit);
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -539,17 +539,17 @@
const NdbError err = pTrans->getNdbError();
if (err.status == NdbError::TemporaryError){
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
if (count_rows != NULL){
*count_rows = rows;
@@ -653,7 +653,7 @@
pOp = pTrans->getNdbScanOperation(tab.getName());
if (pOp == NULL) {
const NdbError err = pNdb->getNdbError();
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
ERR(err);
if (err.status == NdbError::TemporaryError){
@@ -673,14 +673,14 @@
if( rs != 0 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
check = pOp->interpret_exit_ok();
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -689,7 +689,7 @@
if ((row.attributeStore(a) =
pOp->getValue(tab.getColumn(a)->getName())) == 0) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -700,13 +700,13 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -733,13 +733,13 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
goto restart;
}
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -748,17 +748,17 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_OK;
}
@@ -1057,20 +1057,20 @@
pOp = pTrans->getNdbScanOperation(tab.getName());
if (pOp == NULL) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
if( pOp->readTuples(NdbScanOperation::LM_Read, 0, parallelism) ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
check = pOp->interpret_exit_ok();
if( check == -1 ) {
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -1085,13 +1085,13 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -1146,7 +1146,7 @@
g_err << "Error when comapring records" << endl;
g_err << " scanRow: \n" << scanRow.c_str().c_str() << endl;
g_err << " pkRow: \n" << pkRow.c_str().c_str() << endl;
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -1156,7 +1156,7 @@
if((res= iop->nextResult()) != 0){
g_err << "Failed to find row using index: " << res << endl;
ERR(pTrans->getNdbError());
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
@@ -1164,14 +1164,14 @@
g_err << "Error when comapring records" << endl;
g_err << " scanRow: \n" << scanRow.c_str().c_str() << endl;
g_err << " indexRow: \n" << indexRow.c_str().c_str() << endl;
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
if(iop->nextResult() == 0){
g_err << "Found extra row!!" << endl;
g_err << " indexRow: \n" << indexRow.c_str().c_str() << endl;
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
}
@@ -1184,18 +1184,18 @@
if (err.status == NdbError::TemporaryError){
ERR(err);
iop = 0;
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
NdbSleep_MilliSleep(50);
retryAttempt++;
rows--;
continue;
}
ERR(err);
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_FAILED;
}
- pNdb->closeTransaction(pTrans);
+ closeTransaction(pNdb);
return NDBT_OK;
}
@@ -1313,7 +1313,6 @@
HugoCalculator calc(tab);
NDBT_ResultRow row(tab);
- NdbTransaction* pTrans= 0;
const NdbDictionary::Table* tmp= pNdb->getDictionary()->getTable(tab_name2);
if(tmp == 0)
{
@@ -1414,7 +1413,7 @@
}
}
- pTrans->close(); pTrans= 0;
+ closeTransaction(pNdb);
g_info << row_count << " rows compared" << endl;
{
@@ -1432,11 +1431,7 @@
if(err.status == NdbError::TemporaryError)
{
NdbSleep_MilliSleep(50);
- if(pTrans != 0)
- {
- pTrans->close();
- pTrans= 0;
- }
+ closeTransaction(pNdb);
if(cmp.getTransaction())
cmp.closeTransaction(pNdb);
continue;
@@ -1445,7 +1440,17 @@
}
close:
- if(pTrans != 0) pTrans->close();
+ closeTransaction(pNdb);
return return_code;
+}
+
+void
+UtilTransactions::closeTransaction(Ndb* pNdb)
+{
+ if (pTrans != NULL){
+ pTrans->close();
+ pTrans = NULL;
+ }
+ pTrans = NULL;
}
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 9
- InnoDB: Database was not shut down normally!------=_Part_19734_2123004.1192123694303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I get the following message in the .err file after running my mysql++
application:
071011 10:48:07 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 1460518
071011 10:48:07 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
After running the embedded application, the log does not always contain
messages about "Starting an apply batch of log...". However, the "InnoDB:
Database was not shut down normally!" message is consistently there.
If I access the same database via mysqld, I do not see these messages once I
have opened and closed the database a couple of times. I am shutting down
the mysqld before running the embedded app.
I notice in the mysql++ code that mysql_library_end() is not called, but it
seems that the mysql embedded documentation states that this function should
be called. Can anyone shed some light on this?
I'm running the following (all debug configuration):
mysql++-2.3.2 - built on my machine with Microsoft VC++ 2005, linked
against:
mysql sever 5.1 (using the libmysqld.dll that came with the distribution)
------=_Part_19734_2123004.1192123694303--
- 10
- bk commit into 5.0 tree (joreland:1.1876)Below is the list of changes that have just been committed into a local
5.0 repository of jonas. When jonas does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet
1.1876 05/02/21 11:45:51 email***@***.com +2 -0
ndb - ndb_multi - reset query cache at end of test
mysql-test/t/ndb_cache_multi2.test
1.2 05/02/21 11:45:48 email***@***.com +11 -1
reset query cache settings on end of test
mysql-test/r/ndb_cache_multi2.result
1.2 05/02/21 11:45:48 email***@***.com +8 -0
reset query cache settings on end of test
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: joreland
# Host: eel.ndb.mysql.com
# Root: /home/jonas/src/mysql-5.0
--- 1.1/mysql-test/r/ndb_cache_multi2.result Tue Feb 1 15:43:02 2005
+++ 1.2/mysql-test/r/ndb_cache_multi2.result Mon Feb 21 11:45:48 2005
@@ -72,3 +72,11 @@
Variable_name Value
Qcache_hits 0
drop table t1, t2;
+set GLOBAL query_cache_size=0;
+set GLOBAL ndb_cache_check_time=0;
+reset query cache;
+flush status;
+set GLOBAL query_cache_size=0;
+set GLOBAL ndb_cache_check_time=0;
+reset query cache;
+flush status;
--- 1.1/mysql-test/t/ndb_cache_multi2.test Tue Feb 1 15:43:02 2005
+++ 1.2/mysql-test/t/ndb_cache_multi2.test Mon Feb 21 11:45:48 2005
@@ -68,4 +68,14 @@
drop table t1, t2;
-
+# Turn off and reset query cache on server1 and server2
+connection server1;
+set GLOBAL query_cache_size=0;
+set GLOBAL ndb_cache_check_time=0;
+reset query cache;
+flush status;
+connection server2;
+set GLOBAL query_cache_size=0;
+set GLOBAL ndb_cache_check_time=0;
+reset query cache;
+flush status;
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=email***@***.com
- 11
- RequestHello=2C
I was the military assistance to the Minister of Defence of the Federal Republic of Liberia in charge of International Affairs and Logistics=2E
The entire cabinet under the President Charles Taylor has directed that the sum of US28M be set aside for the procurement of arms and ammunitions to fight the rebels in a decade war that is affecting my country and I have decided to siphon the funds with my colleagues through a diplomatic means=2E
I hereby solicit for your partnership and assistance to enable me transfer the fund into your bank account for an investment in your country=2C my life is in danger as I was declared wanted and I have decided to seek asylum in one of the European countries in which you will be notified in due course by my lawyer=2E
All modalities as regards the free transfer of this fund has been perfected as I have estimated 14 banking days to a successful conclusion transfer of this fund through a diplomatic charnel to a security company in The Netherlands in which the name of the security company will be provided after you signify your intension to assist=2E
Once this fund is successfully transfered into your account=2C my colleagues and myself has agreed to share the fund as follows=3A
1=29 30% for you and your company for redering your assistance=2E
2=29 60% for me and colleagues=2C which will in turn be used for investment of any lucrative business in your country=2E
3=29 10% will be used to offset any expenses you may incure during the curse of transaction including your telephone bills=2C traveling expenses e=2Et=2Ec=2E
This transaction is 100% safe and guaranteed since the people involed are of good reputable character in the Government circle who will not want thier name to be identified for security reasons to enable us successfully transfer this fund into your account=2E
You can mail me on=3A johnsondungapati=40yahoo=2Ecom for further discussion on this transaction=2E
Looking forward to do business with you and treat with absolute confidentiality and secrecy and please acknowledge the receipt of this letter=2E
Thanks
JOHNSON DUNGA - APATI=2E
- 12
- How to compile an storage engine as an dll or so?------=_NextPart_000_0005_01C6C04B.4DC19410
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
aGksDQogIEhvdyB0byBjb21waWxlIGFuIHN0b3JhZ2UgZW5naW5lIGFzIGFuIGRsbCBvciBzbz8N
CiAgSSBjb21waWxlZCBNeXNxbCA1LjEuMTEgb24gd2luZG93cyBmb3IgYSBob3VycywgSSBoYXZl
IGNoYW5nZWQgc29tZSB2YzIwMDMgcHJvamVjdCBmaWxlIHN1Y2ggYXMgc3BfYnVpbHRpbi5jcHAu
DQogIEkgY29tcGlsZWQgYWxsIHRoZSBidWlsdGluIHN0b3JhZ2UgZW5naW5lLCBidXQgSSB3YW50
IHRvIHdyaXRlIG15IG93biBzdG9yYWdlIGVuZ2luZSBhcyBkbGwuDQogIEkgaGF2ZSBjaGFuZ2Vk
IGV4YW1wbGUgcHJvamVjdCwgYnV0IHRoZXJlIGlzIGEgbG90IG9mIHN5bWJvbHMgbWlzc2VkLg0K
ICBUaGFua3MhDQogIA0KIA0K
------=_NextPart_000_0005_01C6C04B.4DC19410--
- 13
- Table() returns null------=_Part_2648_8259866.1190912423474
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I managed to solve my problem with the libraries not building properly
by adding in some additional includes into my program. So, now at
least I can connect to my database.
But now I'm having a new problem. One of the things I need to be able
to do for my program is get metadata on the table that I'm pulling
information from.
So I added in this code, based on some of the examples:
Query query = con.query();
String QueryString = "select * from diagnostics";
query << QueryString.cString();
Result res = query.store();
// Query::store() executes the query and returns the results
lprintf("Records Found: %d\n", res.size() );
std::string TableName = res.table();
lprintf("%s:\n", TableName);
for (unsigned int i = 0; i < res.names().size(); i++)
{
String FieldName = res.names(i).c_str();
String SQLType = res.types(i).sql_name();
int Length = res.types(i).length();
lprintf(" Field Name: %s\n", FieldName);
lprintf(" SQL Type: %s\n", SQLType);
lprintf(" Max Length: %d\n\n", Length);
}
return 0;
This works for the most part. Except that I always get (Null) returned for
the Table Name and 0 for the length of the field.
Here's the output:
Records Found: 889
(null):
Field Name: system
SQL Type: VARCHAR NOT NULL
Max Length: 0
Field Name: plane
SQL Type: VARCHAR NOT NULL
Max Length: 0
Field Name: date
SQL Type: DATE NOT NULL
Max Length: 0
Field Name: problem
SQL Type: CHAR NOT NULL
Max Length: 0
I haven't found anything in the documentation that really helps me here.
Any ideas?
Thanks!
David
------=_Part_2648_8259866.1190912423474--
- 14
- problem building the library and examples under windows, usingK _ wrote:
>
> C:\mysql++-2.0.7>c:\cygwin\bin\make.exe
Put c:\cygwin\bin in your Windows PATH. Read the Cygwin documentation
if you don't know how to do this. Then you can just say 'make', and
your other problems should also disappear.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=email***@***.com
- 15
- Connections not closingHi all. It's the first time I write on this newsgroup, I hope you could
help me. I noticed a strange behaviour on MySQL 3.23 under Win 2000
Server. Even if both wait_timeout and interactive_timeout system
variables are set to 28800 seconds (the default) after this time
sleeping connections aren't closed. A similar thing happens if I try to
kill a connection using WinMySqlAdministrator...it says the connection
has been killed, but it remains in the list of active connections (also
after many days...).
Using MySQL 5.0 all works correctly, connections are closed after
wait_timeout and if I kill a connection it is closed in a few seconds.
I tried opening connections with my app (java through jdbc driver),
with sqlyog and with a c++ app. On MySQL 3.23 I've always the same
problem, while on MySQL 5.0 is all ok.
I know on MySQL 3.23 there was a bug closing connections on Solaris
OS...is there a bug also on Windows OS? Unfortunately I can't install
MySQL 5.0 on the server where the app is installed, so I should know if
it's a bug in order to solve it in other ways.
Thanks for any answer!
Elvandar
|
|
|
