svn commit - mysqldoc@docsrva: r3309 - trunk/refman-4.1

[paul]

Author: paul
Date: 2006-09-08 21:11:41 +0200 (Fri, 08 Sep 2006)
New Revision: 3309

Log:
Reformat.


Modified:
   trunk/refman-4.1/database-administration.xml


Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-09-08 19:11:02 UTC (rev 3308)
+++ trunk/refman-4.1/database-administration.xml	2006-09-08 19:11:41 UTC (rev 3309)
Changed blocks: 5, Lines Added: 19, Lines Deleted: 20; 3448 bytes

@@ -12042,8 +12042,8 @@
             <literal>mysql -u <replaceable>other_user</replaceable>
             <replaceable>db_name</replaceable></literal> if
             <replaceable>other_user</replaceable> has no password. If
-            all accounts have a password, connecting using another user's
-            account becomes much more difficult.
+            all accounts have a password, connecting using another
+            user's account becomes much more difficult.
           </para>
 
           <para>

@@ -16250,8 +16250,8 @@
       </para>
 
       <para>
-        The following scenarios are possible for running a 4.1 or
-        later server:
+        The following scenarios are possible for running a 4.1 or later
+        server:
       </para>
 
       <para>

@@ -16628,11 +16628,11 @@
 
         <listitem>
           <para>
-            MySQL usernames can be up to 16 characters
-            long. This limit is hard-coded in the MySQL servers and
-            clients, and trying to circumvent it by modifying the
-            definitions of the tables in the <literal>mysql</literal>
-            database <emphasis>does not work</emphasis>.
+            MySQL usernames can be up to 16 characters long. This limit
+            is hard-coded in the MySQL servers and clients, and trying
+            to circumvent it by modifying the definitions of the tables
+            in the <literal>mysql</literal> database <emphasis>does not
+            work</emphasis>.
           </para>
 
           <para>

@@ -24147,10 +24147,9 @@
       </para>
 
       <para>
-        Cache entries for
-        transactional <literal>InnoDB</literal> tables that have been
-        changed are invalidated when a <literal>COMMIT</literal> is
-        performed.
+        Cache entries for transactional <literal>InnoDB</literal> tables
+        that have been changed are invalidated when a
+        <literal>COMMIT</literal> is performed.
       </para>
 
       <para>

@@ -24483,13 +24482,13 @@
       </para>
 
       <para>
-        When a query is to be cached, its result (the data sent to
-        the client) is stored in the query cache during result
-        retrieval. Therefore the data usually is not handled in one big
-        chunk. The query cache allocates blocks for storing this data on
-        demand, so when one block is filled, a new block is allocated.
-        Because memory allocation operation is costly (timewise), the
-        query cache allocates blocks with a minimum size given by the
+        When a query is to be cached, its result (the data sent to the
+        client) is stored in the query cache during result retrieval.
+        Therefore the data usually is not handled in one big chunk. The
+        query cache allocates blocks for storing this data on demand, so
+        when one block is filled, a new block is allocated. Because
+        memory allocation operation is costly (timewise), the query
+        cache allocates blocks with a minimum size given by the
         <literal>query_cache_min_res_unit</literal> system variable.
         When a query is executed, the last result block is trimmed to
         the actual data size so that unused memory is freed. Depending