Log message:
Pullup ticket #3786 - requested by taca
databases/mysql51-client: security update
databases/mysql51-server: security update

Revisions pulled up:
- databases/mysql51-client/Makefile.common                      1.24-1.25
- databases/mysql51-client/distinfo                             1.21-1.22
- databases/mysql51-server/Makefile                             1.11
- databases/mysql51-server/PLIST                                1.19-1.20
- databases/mysql51-server/distinfo                             1.24-1.25

---
   Module Name:	pkgsrc
   Committed By:	adam
   Date:		Sun Apr  8 19:10:59 UTC 2012

   Modified Files:
   	pkgsrc/databases/mysql51-client: Makefile.common distinfo
   	pkgsrc/databases/mysql51-server: Makefile PLIST distinfo

   Log message:
   Changes 5.1.62:
   * New utf8_general_mysql500_ci and ucs2_general_mysql500_ci collations have
     been added that preserve the behavior of utf8_general_ci and ucs2_general_ci
     from versions of MySQL previous to 5.1.24. Bug 27877 corrected an error in
     the original collations but introduced an incompatibility for columns that
     contain German 'ß' LATIN SMALL LETTER SHARP S. (As a result of the fix, that
     character compares equal to characters with which it previously compared
     different.) A symptom of the problem after upgrading to MySQL 5.1.24 or newer
     from a version older than 5.1.24 is that CHECK TABLE produces this error:
   * yaSSL was upgraded from version 1.7.2 to 2.2.0.
   * Bugs Fixed

---
   Module Name:	pkgsrc
   Committed By:	taca
   Date:		Sun May 13 12:59:39 UTC 2012

   Modified Files:
   	pkgsrc/databases/mysql51-client: Makefile.common distinfo
   	pkgsrc/databases/mysql51-server: PLIST distinfo

   Log message:
   Update mysql51-{client,server} to 5.1.63 (MySQL 5.1.63).

   Changes (http://dev.mysql.com/doc/refman/5.1/en/news-5-1-63.html):

        * Security Fix: Bug #64884 was fixed.

        * Security Fix: Bug #59387 was fixed.

        * InnoDB: Deleting a huge amount of data from InnoDB tables
          within a short time could cause the purge operation that
          flushes data from the buffer pool to stall. If this issue
          occurs, restart the server to work around it. This issue is
          only likely to occur on 32-bit platforms. (Bug #13847885)

        * InnoDB: If the server crashed during a TRUNCATE TABLE or
          CREATE INDEX statement for an InnoDB table, or a DROP DATABASE
          statement for a database containing InnoDB tables, an index
          could be corrupted, causing an error message when accessing
          the table after restart:
          InnoDB: Error: trying to load index index_name for table
          table_name
          InnoDB: but the index tree has been freed!
          In MySQL 5.1, this fix applies to the InnoDB Plugin, but not
          the built-in InnoDB storage engine. (Bug #12861864, Bug
          #11766019)

        * InnoDB: When data was removed from an InnoDB table, newly
          inserted data might not reuse the freed disk blocks, leading
          to an unexpected size increase for the system tablespace or
          .ibd file (depending on the setting of innodb_file_per_table.
          The OPTIMIZE TABLE could compact a .ibd file in some cases but
          not others. The freed disk blocks would eventually be reused
          as additional data was inserted. (Bug #11766634, Bug #59783)

        * Partitioning: After updating a row of a partitioned table and
          selecting that row within the same transaction with the query
          cache enabled, then performing a ROLLBACK, the same result was
          returned by an identical SELECT issued in a new transaction.
          (Bug #11761296, Bug #53775)

        * Replication: The --relay-log-space-limit option was sometimes
          ignored.
          More specifically, when the SQL thread went to sleep, it
          allowed the I/O thread to queue additional events in such a
          way that the relay log space limit was bypassed, and the
          number of events in the queue could grow well past the point
          where the relay logs needed to be rotated. Now in such cases,
          the SQL thread checks to see whether the I/O thread should
          rotate and provide the SQL thread a chance to purge the logs
          (thus freeing space).
          Note that, when the SQL thread is in the middle of a
          transaction, it cannot purge the logs; it can only ask for
          more events until the transaction is complete. Once the
          transaction is finished, the SQL thread can immediately
          instruct the I/O thread to rotate. (Bug #12400313, Bug #64503)
          References: See also Bug #13806492.

        * Mishandling of NO_BACKSLASH_ESCAPES SQL mode within stored
          procedures on slave servers could cause replication failures.
          (Bug #12601974)

        * If the system time was adjusted backward during query
          execution, the apparent execution time could be negative. But
          in some cases these queries would be written to the slow query
          log, with the negative execution time written as a large
          unsigned number. Now statements with apparent negative
          execution time are not written to the slow query log. (Bug
          #63524, Bug #13454045) References: See also Bug #27208.

        * mysql_store_result() and mysql_use_result() are not for use
          with prepared statements and are not intended to be called
          following mysql_stmt_execute(), but failed to return an error
          when invoked that way in libmysqld. (Bug #62136, Bug
          #13738989) References: See also Bug #47485.

        * SHOW statements treated stored procedure, stored function, and
          event names as case sensitive. (Bug #56224, Bug #11763507)

        * On Windows, mysqlslap crashed for attempts to connect using
          shared memory. (Bug #31173, Bug #11747181, Bug #59107, Bug
          #11766072)