From: John Embretsen Date: July 3 2009 11:51am Subject: Weekly Falcon bazaar merge List-Archive: http://lists.mysql.com/falcon/781 Message-Id: <4A4DF0DC.4090806@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary_(ID_W6T2R7mFSp6I/dcYqh186Q)" --Boundary_(ID_W6T2R7mFSp6I/dcYqh186Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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 --Boundary_(ID_W6T2R7mFSp6I/dcYqh186Q) Content-type: text/plain; name=merged-from-falcon-team-to-falcon_2009-07-03.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=merged-from-falcon-team-to-falcon_2009-07-03.txt 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. --Boundary_(ID_W6T2R7mFSp6I/dcYqh186Q)--