Weekly Falcon bazaar merge

[John Embretsen]

Hi falconers,

I just finished a merge of our bazaar branches

   mysql-6.0-falcon-team (private) --> mysql-6.0-falcon (public)


Commit comments from the merged revisions are attached to this E-mail.

As always, please test your code tree for unusual problems such as
compile errors or the like.

The latest merge will appear in the public falcon branch on Launchpad
within a couple of hours. You can create your own local branch from
launchpad:

bzr branch lp:~mysql/mysql-server/mysql-6.0-falcon

(see https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-falcon)


Regards,

-- 
John


Merged 9 revision(s):
------------------------------------------------------------
revno: 2732 [merge]
committer: John H. Embretsen 
branch nick: mysql-6.0-falcon-to-merge
timestamp: Fri 2009-07-03 13:41:35 +0200
message:
  Merge mysql-6.0-falcon-team --> mysql-6.0-falcon.
    ------------------------------------------------------------
    revno: 2729.1.23
    committer: John H. Embretsen 
    branch nick: mysql-6.0-falcon-team-jsandbox
    timestamp: Fri 2009-07-03 13:14:02 +0200
    message:
      Bump Falcon's internal version number.
      We try to do this every time we merge upwards. This also makes it easier for
developers to compare the ages of different codebases.
    ------------------------------------------------------------
    revno: 2729.1.22 [merge]
    committer: lars-erik.bjork
    branch nick: cleanup
    timestamp: Wed 2009-07-01 12:45:50 +0200
    message:
      merging ...
        ------------------------------------------------------------
        revno: 2729.6.1
        committer: Christopher Powers 
        branch nick: mysql
        timestamp: Sun 2009-06-28 13:58:38 -0500
        message:
          Bug #45775, "Crash when adding primary key to Falcon table with unique
constraint."
          
          There are several issues here:
          
          1) The server assigns TABLE->s->primary_key != MAX_KEY for EITHER a
primary key
             OR a unique key with non-null columns.
          
          2) Falcon assumed ::primary_key unambiguously identifies ONLY the primary key,
             and therfore incorrectly interpreted (a INT NOT NULL UNIQUE) as being a
             primary key declaration.
          
          3) Given (2), the command "ALTER TABLE ADD PRIMARY KEY (b)" caused an update
             conflict for which Falcon raised an exception that subsequently crashed.
          
          4) The crash was caused by a null pointer encountered during exception handling.
          
          Item 4 was easy to fix. Item 2, not so easy.
          
          Fortunately, the server always names the primary key "PRIMARY", so to
          distinguish between a primary key and a unique, non-null key, Falcon now checks
          the key name.
    ------------------------------------------------------------
    revno: 2729.1.21
    committer: lars-erik.bjork
    branch nick: cleanup
    timestamp: Wed 2009-07-01 11:02:00 +0200
    message:
      IndexRootPage::splitIndexPage has a return statement that will never be exercised.
This is probably because
      of multiple rewrites of the method. Because of this, there is really no need for the
method to be declared
      to return a bool, as 'false' always will be the returned value. Changing the
declaration to void, improves the readability of the code, and allows us to
      readability and allows us to remove two if-statements
    ------------------------------------------------------------
    revno: 2729.1.20 [merge]
    committer: Olav.Sandstaa
    branch nick: falcon-elog
    timestamp: Fri 2009-06-26 21:54:33 +0200
    message:
      Merging...
        ------------------------------------------------------------
        revno: 2729.5.2 [merge]
        committer: Kevin Lewis 
        branch nick: mysql-6.0-falcon-team
        timestamp: Fri 2009-06-26 07:51:06 -0600
        message:
          merge
        ------------------------------------------------------------
        revno: 2729.5.1
        committer: Kevin Lewis 
        branch nick: mysql-6.0-falcon-team
        timestamp: Thu 2009-06-25 16:48:40 -0600
        message:
          Bug#45701 - If a table has two foreign key relationships with one other table,
an alter table that drops one of the FKs will call external_lock twice for each table.
And if a table has a foreign key relationship with another table, an alter that creates
another foreign key relationship between the two tables will also call external_lock
twice for each table.
          
          So it is necessary for Falcon to support multiple calls to external_lock by the
same connection to the same table.  This was not needed before the Foriegn Key
implementation.  
          
          So the current Connection pointer is sent into Table::SetAlter() and stored in
Table::alterConnection.   And alterIsActive is now an int instead of a boolean.  If the
same connection locks the table a second time, alterIsActive is incremented and
alterConnection remains set.  It is not set to NULL until alterIsActive is decremented to
zero.
    ------------------------------------------------------------
    revno: 2729.1.19
    committer: Olav.Sandstaa
    branch nick: falcon-elog
    timestamp: Fri 2009-06-26 13:13:44 +0200
    message:
      Bug#43490 Falcon internal thread terminate after throwing an instance of 'SQLError'
      
      The thrown exception contains the error string "can't continue after
      fatal error ". This exception is only thrown by the Falcon IO
      system. It is thrown after a fatal IO error has
      occurred. Unfortunately it gives very little information about what
      the actual error was.
      
      This patch improves the logging of "fatal" IO errors by writing to the
      error log file information about the error when it occurs. With this
      patch a message similar to this example will be written when
      IO::declareFatalError() is called:
      
      Falcon: Fatal IO error occurred in "IO::writePages": file
      "/home/olav/mysql/develop/falcon-elog/mysql-test/var/mysqld.1/data/falcon_user.fts",
page 21: No space left on device (28)
      
      Note that this patch does not fix the problem but only improves the logging
      when the actually error occurs, hopefully making it easier to find the
      real error.