| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | October 29 2007 7:28pm |
| Subject: | svn commit - mysqldoc@docsrva: r8390 - in trunk: . dynamic-docs/changelog refman-5.2 | ||
| View as plain text | |||
Author: paul Date: 2007-10-29 19:28:29 +0100 (Mon, 29 Oct 2007) New Revision: 8390 Log: r31921@polar: paul | 2007-10-29 13:27:02 -0500 Documented bugfixes: Bug#25858: Some DROP TABLE under LOCK TABLES can cause deadlocks This changes some DROP TABLE behavior; noted in upgrading, DROP TABLE, LOCK TABLES sections. Modified: trunk/dynamic-docs/changelog/mysqld.xml trunk/refman-5.2/installing.xml trunk/refman-5.2/sql-syntax.xml trunk/refman-5.2/triggers.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:31898 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:26290 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:21581 + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:31921 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:26290 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:21581 Modified: trunk/dynamic-docs/changelog/mysqld.xml =================================================================== --- trunk/dynamic-docs/changelog/mysqld.xml 2007-10-29 18:08:20 UTC (rev 8389) +++ trunk/dynamic-docs/changelog/mysqld.xml 2007-10-29 18:28:29 UTC (rev 8390) Changed blocks: 1, Lines Added: 36, Lines Deleted: 0; 1231 bytes @@ -139035,4 +139035,40 @@ </logentry> + <logentry entrytype="bug"> + + <tags> + <highlight type="incompatiblechange"/> + <manual type="DROP TABLE"/> + <manual type="locking"/> + </tags> + + <bugs> + <fixes bugid="25858"/> + </bugs> + + <versions> + <version ver="6.0.3"/> + </versions> + + <message> + + <para> + <literal>DROP TABLE</literal> now is allowed only if you have + acquired a <literal>WRITE</literal> lock with <literal>LOCK + TABLES</literal>, or if you hold no locks, or if the table is a + <literal>TEMPORARY</literal> table. + </para> + + <para> + Previously, if other tables were locked, you could drop a table + with a read lock or no lock, which could lead to deadlocks + between clients. The new stricter behavior means that some usage + scenarios will fail when previously they did not. + </para> + + </message> + + </logentry> + </changelog> Modified: trunk/refman-5.2/installing.xml =================================================================== --- trunk/refman-5.2/installing.xml 2007-10-29 18:08:20 UTC (rev 8389) +++ trunk/refman-5.2/installing.xml 2007-10-29 18:28:29 UTC (rev 8390) Changed blocks: 9, Lines Added: 32, Lines Deleted: 486; 24170 bytes @@ -12042,7 +12042,7 @@ <listitem> <para> Before upgrading from MySQL &previous-series; to - ¤t-series;, read <xref linkend="upgrading-from-5-0"/>, + ¤t-series;, read <xref linkend="upgrading-from-5-1"/>, as well as <xref linkend="news"/>. These provide information about features that are new in MySQL ¤t-series; or differ from those found in MySQL &previous-series;. If you @@ -12185,9 +12185,9 @@ Python <literal>MySQLdb</literal> module. </para> - <section id="upgrading-from-5-0"> + <section id="upgrading-from-5-1"> - <title>Upgrading from MySQL 5.0 to 5.1</title> + <title>Upgrading from MySQL 5.1 to 6.0</title> <indexterm> <primary>compatibility</primary> @@ -12199,15 +12199,6 @@ <secondary>to ¤t-series;</secondary> </indexterm> - <para> - <emphasis role="bold">When upgrading a 5.0 installation to - 5.0.10 or above</emphasis> note that it is - <emphasis>necessary</emphasis> to upgrade your grant tables. - Otherwise, creating stored procedures and functions might not - work. The procedure for doing this is described in - <xref linkend="mysql-upgrade"/>. - </para> - <note> <para> It is good practice to back up your data before installing any @@ -12297,6 +12288,12 @@ MySQL ¤t-series;. </para> + <remark> + Uncomment the following block and remove this remark if any + configuration changes are noted + </remark> + +<!-- <para> <emphasis role="bold">Configuration Changes:</emphasis> </para> @@ -12305,22 +12302,11 @@ <listitem> <para> - Before MySQL 5.1.11, to build MySQL from source with SSL - support enabled, you would invoke - <command>configure</command> with either the - <option>--with-openssl</option> or - <option>--with-yassl</option> option. In MySQL 5.1.11, those - options both have been replaced by the - <option>--with-ssl</option> option. By default, - <option>--with-ssl</option> causes the bundled yaSSL library - to be used. To select OpenSSL instead, give the option as - <option>--with-ssl=<replaceable>path</replaceable></option>, - where <replaceable>path</replaceable> is the directory where - the OpenSSL header files and libraries are located. </para> </listitem> </itemizedlist> +--> <para> <emphasis role="bold">Server Changes:</emphasis> @@ -12330,308 +12316,27 @@ <listitem> <para> - <emphasis role="bold">Incompatible change</emphasis>: MySQL - ¤t-series; implements support for a plugin API that - allows the loading and unloading of components at runtime, - without restarting the server. <xref linkend="plugin-api"/>. - The plugin API requires the <literal>mysql.plugin</literal> - table. When upgrading from an older version of MySQL, you - should run the <command>mysql_upgrade</command> command to - create this table. See <xref linkend="mysql-upgrade"/>. - </para> - - <para> - Plugins are installed in the directory named by the - <literal>plugin_dir</literal> system variable. This variable - also controls the location from which the server loads - user-defined functions (UDFs), which is a change from - earlier versions of MySQL. That is, all UDF library files - now must be installed in the plugin directory. When - upgrading from an older version of MySQL, you must migrate - your UDF files to the plugin directory. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: The - <literal>table_cache</literal> system variable has been - renamed to <literal>table_open_cache</literal>. Any scripts - that refer to <literal>table_cache</literal> should be - updated to use the new name. - </para> - </listitem> - - <listitem> - <para> <emphasis role="bold">Incompatible change</emphasis>: As of - MySQL 5.1.15, the following conditions apply to enabling the - <literal>read_only</literal> system variable: + MySQL 6.0.3, <literal>DROP TABLE</literal> is allowed only + if you have acquired a <literal>WRITE</literal> lock with + <literal>LOCK TABLES</literal>, or if you hold no locks, or + if the table is a <literal>TEMPORARY</literal> table. </para> - <itemizedlist> - - <listitem> - <para> - If you attempt to enable <literal>read_only</literal> - while you have any explicit locks (acquired with - <literal>LOCK TABLES</literal> or have a pending - transaction, an error will occur. - </para> - </listitem> - - <listitem> - <para> - If other clients hold explicit table locks or have - pending transactions, the attempt to enable - <literal>read_only</literal> blocks until the locks are - released and the transactions end. While the attempt to - enable <literal>read_only</literal> is pending, requests - by other clients for table locks or to begin - transactions also block until - <literal>read_only</literal> has been set. - </para> - </listitem> - - <listitem> - <para> - <literal>read_only</literal> can be enabled while you - hold a global read lock (acquired with <literal>FLUSH - TABLES WITH READ LOCK</literal>) because that does not - involve table locks. - </para> - -<!-- -This means that the following - sequence of statements can be used to place a server in - read-only state prior to performing a backup: - </para> - -<programlisting> -FLUSH TABLES WITH READ LOCK; -SET GLOBAL read_only = ON; -UNLOCK TABLES; -</programlisting> ---> - </listitem> - - </itemizedlist> - <para> - Previously, the attempt to enable - <literal>read_only</literal> would return immediately even - if explicit locks or transactions were pending, so some data - changes could occur for statements executing in the server - at the same time. + Previously, if other tables were locked, you could drop a + table with a read lock or no lock, which could lead to + deadlocks between clients. The new stricter behavior means + that some usage scenarios will fail when previously they did + not. </para> </listitem> - <listitem> - <important> - <para> - Previously, duplicate-key errors were indicated by the - <literal>ER_DUP_ENTRY</literal> error code (1062). As of - MySQL 5.1.15, this code is no longer used. Instead, the - server returns - <literal>ER_DUP_ENTRY_WITH_KEY_NAME</literal> (1582), and - the error message indicates the name of the index for - which the duplicate occurred. Applications that test for - duplicate keys should look for both error codes if they - need to be compatible with current and older servers. - </para> - </important> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: The - number of function names affected by - <literal>IGNORE_SPACE</literal> was reduced significantly in - MySQL 5.1.13, from about 200 to about 30. (For details about - <literal>IGNORE_SPACE</literal>, see - <xref linkend="function-resolution"/>.) This change improves - the consistency of parser operation. However, it also - introduces the possibility of incompatibility for old SQL - code that relies on the following conditions: - </para> - - <itemizedlist> - - <listitem> - <para> - <literal>IGNORE_SPACE</literal> is disabled. - </para> - </listitem> - - <listitem> - <para> - The presence or absence of whitespace following a - function name is used to distinguish between a built-in - function and stored function that have the same name - (for example, <literal>PI()</literal> versus <literal>PI - ()</literal>). - </para> - </listitem> - - </itemizedlist> - - <para> - For functions that are no longer affected by - <literal>IGNORE_SPACE</literal> as of MySQL 5.1.13, that - strategy no longer works. Either of the following approaches - can be used if you have code that is subject to the - preceding incompatibility: - </para> - - <itemizedlist> - - <listitem> - <para> - If a stored function has a name that conflicts with a - built-in function, refer to the stored function with a - schema name qualifier, regardless of whether whitespace - is present. For example, write - <literal><replaceable>schema_name</replaceable>.PI()</literal> - or <literal><replaceable>schema_name</replaceable>.PI - ()</literal>. - </para> - </listitem> - - <listitem> - <para> - Alternatively, rename the stored function to use a - non-conflicting name and change invocations of the - function to use the new name. - </para> - </listitem> - - </itemizedlist> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: For - <literal>utf8</literal> columns, the full-text parser - incorrectly considered several non-word punctuation and - whitespace characters as word characters, causing some - searches to return incorrect results. The fix involves a - change to the full-text parser in MySQL 5.1.12, so as of - 5.1.12, any tables that have <literal>FULLTEXT</literal> - indexes on <literal>utf8</literal> columns must be repaired - with <literal>REPAIR TABLE</literal>: - </para> - -<programlisting> -REPAIR TABLE <replaceable>tbl_name</replaceable> QUICK; -</programlisting> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: - Storage engines can be pluggable at runtime, so the - distinction between disabled and invalid storage engines no - longer applies. As of MySQL 5.1.12, this affects the - <literal>NO_ENGINE_SUBSTITUTION</literal> SQL mode, as - described in <xref linkend="server-sql-mode"/>. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: The - structure of <literal>FULLTEXT</literal> indexes has been - changed in MySQL 5.1.6. After upgrading to MySQL 5.1.6 or - greater, call the <literal>REPAIR TABLE</literal> statement - for each table that contains any <literal>FULLTEXT</literal> - indexes. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: Before - MySQL 5.1.6, the server writes general query log and slow - query log entries to log files. As of MySQL 5.1.6, the - server's logging capabilities for these logs are more - flexible. Log entries can be written to log files (as - before) or to the <literal>general_log</literal> and - <literal>slow_log</literal> tables in the - <literal>mysql</literal> database. If logging is enabled, - either or both destinations can be selected. The - <option>--log-output</option> option controls the - destination or destinations of log output. See - <xref linkend="log-tables"/>. - </para> - - <para> - If logging is enabled, the default destination now is to log - to tables, which differs from earlier versions. If you had - the server configured for logging to log files formerly, use - <option>--log-output=FILE</option> to preserve this behavior - after an upgrade to MySQL 5.1.6 or higher. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: For - <literal>ENUM</literal> columns that had enumeration values - containing commas, the commas were mapped to 0xff - internally. However, this rendered the commas - indistinguishable from true 0xff characters in the values. - This no longer occurs. However, the fix requires that you - dump and reload any tables that have <literal>ENUM</literal> - columns containing true 0xff in their values: Dump the - tables using <command>mysqldump</command> with the current - server before upgrading from a version of MySQL 5.1 older - than 5.1.15 to version 5.1.15 or newer. - </para> - </listitem> - - <listitem> - <para> - As of MySQL 5.1.12, the <literal>lc_time_names</literal> - system variable specifies the locale that controls the - language used to display day and month names and - abbreviations. This variable affects the output from the - <literal>DATE_FORMAT()</literal>, - <literal>DAYNAME()</literal> and - <literal>MONTHNAME()</literal> functions. See - <xref linkend="locale-support"/>. - </para> - </listitem> - - <listitem> - <para> - As of MySQL 5.1.6, special characters in database and table - identifiers are encoded when creating the corresponding - directory names and filenames. This relaxes the restrictions - on the characters that can appear in identifiers. See - <xref linkend="identifier-mapping"/>. When you run - <command>mysql_upgrade</command>, it will cause database and - table names to be updated to the new format should they - contain special characters. - </para> - </listitem> - - <listitem> - <para> - As of MySQL 5.1.9, <command>mysqld_safe</command> no longer - implicitly invokes <command>mysqld-max</command> if it - exists. Instead, it invokes <command>mysqld</command> unless - a <option>--mysqld</option> or - <option>--mysqld-version</option> option is given to specify - another server explicitly. If you previously relied on the - implicit invocation of <command>mysqld-max</command>, you - should use an appropriate option now. - </para> - </listitem> - </itemizedlist> <remark> - Uncomment this block if any client changes are noted + Uncomment the following block and remove this remark if any + client changes are noted </remark> <!-- @@ -12652,6 +12357,12 @@ </itemizedlist> --> + <remark> + Uncomment the following block and remove this remark if any C + API changes are noted + </remark> + +<!-- <para> <emphasis role="bold">SQL Changes:</emphasis> </para> @@ -12660,179 +12371,18 @@ <listitem> <para> - <emphasis role="bold">Incompatible change</emphasis>: As of - MySQL 5.1.8, <literal>TYPE = - <replaceable>engine_name</replaceable></literal> is still - accepted as a synonym for the <literal>ENGINE = - <replaceable>engine_name</replaceable></literal> table - option but generates a warning. You should note that this - option is not available in MySQL 5.1.7, and - <emphasis role="bold">is to be removed altogether in MySQL - 5.2, where it will produce a syntax error</emphasis>. </para> - - <para> - <literal>TYPE</literal> has been deprecated since MySQL 4.0. - </para> </listitem> - <listitem> - <para> - <emphasis role="bold">Incompatible change:</emphasis> The - namespace for triggers has changed in MySQL 5.0.10. - Previously, trigger names had to be unique per table. Now - they must be unique within the schema (database). An - implication of this change is that <literal>DROP - TRIGGER</literal> syntax now uses a schema name instead of a - table name (schema name is optional and, if omitted, the - current schema will be used). - </para> - - <para> - When upgrading from a previous version of MySQL 5 to MySQL - 5.0.10 or newer, you must drop all triggers and re-create - them or <literal>DROP TRIGGER</literal> will not work after - the upgrade. Here is a suggested procedure for doing this: - </para> - - <orderedlist> - - <listitem> - <para> - Upgrade to MySQL 5.0.10 or later to be able to access - trigger information in the - <literal>INFORMATION_SCHEMA.TRIGGERS</literal> table. - (It should work even for pre-5.0.10 triggers.) - </para> - </listitem> - - <listitem> - <para> - Dump all trigger definitions using the following - <literal>SELECT</literal> statement: - </para> - -<programlisting> -SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME, - ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ', - t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE, - ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' ) -INTO OUTFILE '/tmp/triggers.sql' -FROM INFORMATION_SCHEMA.TRIGGERS AS t; -</programlisting> - - <para> - The statement uses <literal>INTO OUTFILE</literal>, so - you must have the <literal>FILE</literal> privilege. The - file will be created on the server host; use a different - filename if you like. To be 100% safe, inspect the - trigger definitions in the - <filename>triggers.sql</filename> file, and perhaps make - a backup of the file. - </para> - </listitem> - - <listitem> - <para> - Stop the server and drop all triggers by removing all - <filename>.TRG</filename> files in your database - directories. Change location to your data directory and - issue this command: - </para> - -<programlisting> -shell> <userinput>rm */*.TRG</userinput> -</programlisting> - </listitem> - - <listitem> - <para> - Start the server and re-create all triggers using the - <filename>triggers.sql</filename> file: For example in - my case it was: - </para> - -<programlisting> -mysql> <userinput>delimiter // ;</userinput> -mysql> <userinput>source /tmp/triggers.sql //</userinput> -</programlisting> - </listitem> - - <listitem> - <para> - Check that all triggers were successfully created using - the <filename>SHOW TRIGGERS</filename> statement. - </para> - </listitem> - - </orderedlist> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Incompatible change</emphasis>: MySQL - 5.1.6 introduces the <literal>TRIGGER</literal> privilege. - Previously, the <literal>SUPER</literal> privilege was - needed to create or drop triggers. Now those operations - require the <literal>TRIGGER</literal> privilege. This is a - security improvement because you no longer need to grant - users the <literal>SUPER</literal> privilege to enable them - to create triggers. However, the requirement that the - account named in a trigger's <literal>DEFINER</literal> - clause must have the <literal>SUPER</literal> privilege has - changed to a requirement for the <literal>TRIGGER</literal> - privilege. When upgrading from a previous version of MySQL - 5.0 or 5.1 to MySQL 5.1.6 or newer, be sure to update your - grant tables as described in - <xref linkend="mysql-upgrade"/>. This process assigns the - <literal>TRIGGER</literal> privilege to all accounts that - had the <literal>SUPER</literal> privilege. If you fail to - update the grant tables, triggers may fail when activated. - (After updating the grant tables, you can revoke the - <literal>SUPER</literal> privilege from those accounts that - no longer otherwise require it.) - </para> - </listitem> - - <listitem> - <para> - Some keywords are reserved in MySQL ¤t-series; that - were not reserved in MySQL &previous-series;. See - <xref linkend="reserved-words"/>. - </para> - </listitem> - - <listitem> - <para> - The <literal>LOAD DATA FROM MASTER</literal> and - <literal>LOAD TABLE FROM MASTER</literal> statements are no - longer supported. You can continue to use - <command>mysqldump</command> (see - <xref linkend="mysqldump"/>) or - <command>mysqlhotcopy</command> (see - <xref linkend="mysqlhotcopy"/>) instead. See - <xref linkend="ha-overview"/>, for other recommended - alternative backup and restoration solutions. - </para> - </listitem> - - <listitem> - <para> - The <literal>INSTALL PLUGIN</literal> and <literal>UNINSTALL - PLUGIN</literal> statements that are used for the plugin API - are new. So is the <literal>WITH PARSER</literal> clause for - <literal>FULLTEXT</literal> index creation that associates a - parser plugin with a full-text index. - <xref linkend="plugin-api"/>. - </para> - </listitem> - </itemizedlist> +--> <remark> - Uncomment this block if any C API changes are noted + Uncomment the following block and remove this remark if any C + API changes are noted </remark> +<!-- <para> <emphasis role="bold">C API Changes:</emphasis> </para> @@ -12841,15 +12391,11 @@ <listitem> <para> - <emphasis role="bold">Incompatible change</emphasis>: As of - MySQL 5.1.7, the - <function role="capi">mysql_stmt_attr_get()</function> C API - function returns a boolean rather than an unsigned int for - <literal>STMT_ATTR_UPDATE_MAX_LENGTH</literal>. (Bug #16144) </para> </listitem> </itemizedlist> +--> </section> Modified: trunk/refman-5.2/sql-syntax.xml =================================================================== --- trunk/refman-5.2/sql-syntax.xml 2007-10-29 18:08:20 UTC (rev 8389) +++ trunk/refman-5.2/sql-syntax.xml 2007-10-29 18:28:29 UTC (rev 8390) Changed blocks: 2, Lines Added: 27, Lines Deleted: 5; 2317 bytes @@ -5661,6 +5661,17 @@ table. </para> + <para> + As of MySQL 6.0.3, <literal>DROP TABLE</literal> is allowed only + if you have acquired a <literal>WRITE</literal> lock with + <literal>LOCK TABLES</literal>, or if you hold no locks, or if + the table is a <literal>TEMPORARY</literal> table. (Previously, + if other tables were locked, you could drop a table with a read + lock or no lock, which could lead to deadlocks between clients. + The new stricter behavior means that some usage scenarios will + fail when previously they did not.) + </para> + </section> <section id="drop-tablespace"> @@ -14845,13 +14856,24 @@ <para> A table lock protects only against inappropriate reads or writes - by other clients. The client holding the lock, even a read lock, - can perform table-level operations such as <literal>DROP - TABLE</literal>. Truncate operations are not transaction-safe, - so an error occurs if the client attempts one during an active - transaction or while holding a table lock. + by other clients. The client holding the lock can perform + table-level operations such as <literal>DROP TABLE</literal>. + Truncate operations are not transaction-safe, so an error occurs + if the client attempts one during an active transaction or while + holding a table lock. </para> + <para> + As of MySQL 6.0.3, <literal>DROP TABLE</literal> is allowed only + if you have acquired a <literal>WRITE</literal> lock with + <literal>LOCK TABLES</literal>, or if you hold no locks, or if + the table is a <literal>TEMPORARY</literal> table. (Previously, + if other tables were locked, you could drop a table with a read + lock or no lock, which could lead to deadlocks between clients. + The new stricter behavior means that some usage scenarios will + fail when previously they did not.) + </para> + <remark role="help-description-end"/> <para> Modified: trunk/refman-5.2/triggers.xml =================================================================== --- trunk/refman-5.2/triggers.xml 2007-10-29 18:08:20 UTC (rev 8389) +++ trunk/refman-5.2/triggers.xml 2007-10-29 18:28:29 UTC (rev 8390) Changed blocks: 1, Lines Added: 0, Lines Deleted: 12; 848 bytes @@ -536,18 +536,6 @@ <remark role="help-description-end"/> - <note> - <para> - When upgrading from a version of MySQL older than MySQL 5.0.10 - to 5.0.10 or newer — including all MySQL ¤t-series; - releases — you must drop all triggers <emphasis>before - upgrading</emphasis> and re-create them afterward, or else - <literal>DROP TRIGGER</literal> does not work after the upgrade. - See <xref linkend="upgrading-from-5-0"/>, for a suggested - upgrade procedure. - </para> - </note> - </section> <section id="using-triggers">
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r8390 - in trunk: . dynamic-docs/changelog refman-5.2 | paul | 29 Oct |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.741 sec. using MySQL 5.1.14-beta-log