bk commit - mysqldoc@docsrva tree (paul:1.3134)

[paul]

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.3134 05/07/26 19:44:08 paul@stripped +3 -0
  Point out potential for lock denial with
  GET_LOCK(). Suggest workaround.

  refman/functions.xml
    1.13 05/07/26 19:44:06 paul@stripped +13 -4
    Point out potential for lock denial with
    GET_LOCK(). Suggest workaround.

  refman-5.0/functions.xml
    1.17 05/07/26 19:44:06 paul@stripped +14 -6
    Sync.

  refman-4.1/functions.xml
    1.14 05/07/26 19:44:05 paul@stripped +13 -4
    Sync.

# 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:	frost.snake.net
# Root:	/Volumes/frost2/MySQL/bk/mysqldoc

--- 1.13/refman-4.1/functions.xml	2005-07-22 02:58:53 -05:00
+++ 1.14/refman-4.1/functions.xml	2005-07-26 19:44:05 -05:00
@@ -6427,9 +6427,9 @@
 
         <para>
           Use <literal>FROM_DAYS()</literal> with caution on old dates.
-          It is not intended for use with values that precede the advent 
-          of the Gregorian calendar (1582).
-          See <xref linkend="mysql-calendar"/>.
+          It is not intended for use with values that precede the advent
+          of the Gregorian calendar (1582). See
+          <xref linkend="mysql-calendar"/>.
         </para>
 
 <!--  description_for_help_topic FROM_UNIXTIME -->
@@ -11607,7 +11607,16 @@
             <literal>GET_LOCK()</literal> blocks any request by another
             client for a lock with the same name. This allows clients
             that agree on a given lock name to use the name to perform
-            cooperative advisory locking.
+            cooperative advisory locking. But be aware that it also
+            allows a client that is not among the set of cooperating
+            clients to lock a name, either inadvertently or
+            deliberately, and thus prevent any of the cooperating
+            clients from locking that name. One way to reduce the
+            likelihood of this is to use lock names that are
+            database-specific or application-specific. For example, use
+            lock names of the form
+            <replaceable>db_name.str</replaceable> or
+            <replaceable>app_name.str</replaceable>.
           </para>
 
 <!--  end_description_for_help_topic -->

--- 1.16/refman-5.0/functions.xml	2005-07-19 10:57:29 -05:00
+++ 1.17/refman-5.0/functions.xml	2005-07-26 19:44:06 -05:00
@@ -6635,10 +6635,9 @@
 </programlisting>
 
         <para>
-          <literal>FROM_DAYS()</literal> is not intended for use with
-          values that precede the advent of the Gregorian calendar
-          (1582), because it does not take into account the days that
-          were lost when the calendar was changed. See
+          Use <literal>FROM_DAYS()</literal> with caution on old dates.
+          It is not intended for use with values that precede the advent
+          of the Gregorian calendar (1582). See
           <xref linkend="mysql-calendar"/>.
         </para>
 
@@ -11791,10 +11790,19 @@
             <literal>GET_LOCK()</literal> blocks any request by another
             client for a lock with the same name. This allows clients
             that agree on a given lock name to use the name to perform
-            cooperative advisory locking.
+            cooperative advisory locking. But be aware that it also
+            allows a client that is not among the set of cooperating
+            clients to lock a name, either inadvertently or
+            deliberately, and thus prevent any of the cooperating
+            clients from locking that name. One way to reduce the
+            likelihood of this is to use lock names that are
+            database-specific or application-specific. For example, use
+            lock names of the form
+            <replaceable>db_name.str</replaceable> or
+            <replaceable>app_name.str</replaceable>.
+          </para>
 
 <!--  end_description_for_help_topic -->
-          </para>
 
           <para>
 <!--  example_for_help_topic GET_LOCK -->

--- 1.12/refman/functions.xml	2005-07-22 02:58:15 -05:00
+++ 1.13/refman/functions.xml	2005-07-26 19:44:06 -05:00
@@ -6432,9 +6432,9 @@
 
         <para>
           Use <literal>FROM_DAYS()</literal> with caution on old dates.
-          It is not intended for use with values that precede the advent 
-          of the Gregorian calendar (1582).
-          See <xref linkend="mysql-calendar"/>.
+          It is not intended for use with values that precede the advent
+          of the Gregorian calendar (1582). See
+          <xref linkend="mysql-calendar"/>.
         </para>
 
 <!--  description_for_help_topic FROM_UNIXTIME -->
@@ -11612,7 +11612,16 @@
             <literal>GET_LOCK()</literal> blocks any request by another
             client for a lock with the same name. This allows clients
             that agree on a given lock name to use the name to perform
-            cooperative advisory locking.
+            cooperative advisory locking. But be aware that it also
+            allows a client that is not among the set of cooperating
+            clients to lock a name, either inadvertently or
+            deliberately, and thus prevent any of the cooperating
+            clients from locking that name. One way to reduce the
+            likelihood of this is to use lock names that are
+            database-specific or application-specific. For example, use
+            lock names of the form
+            <replaceable>db_name.str</replaceable> or
+            <replaceable>app_name.str</replaceable>.
           </para>
 
 <!--  end_description_for_help_topic -->