An error occurred fetching the project authors.
- 06 Oct, 2010 1 commit
-
-
Davi Arnaut authored
Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
-
- 08 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives.
-
- 11 Dec, 2009 1 commit
-
-
V Narayanan authored
This fix changes the character set used within the IBMDB2I handler to hash table names to information about open tables. Previously, tables with names that differed only in letter case would hash to the same data structure. This caused incorrect behavior or errors when two such tables were in use simultaneously.
-
- 17 Nov, 2009 1 commit
-
-
MySQL Build Team authored
Recently, the "#define" directives mapping the old names to the new ones have been removed, so now all callers must use the new names. This change was missing in the DB2 storage handler modules.
-
- 08 Jul, 2009 1 commit
-
-
V Narayanan authored
With ibmdb2i_create_index_option set to 1, creating an IBMDB2I table with a primary key should produce an additional index that uses EBCDIC hexadecimal sorting. However, this does not work. Adding indexes that are not primary keys does work. The ibmdb2i_create_index_option should be honoured when creating a table with a primary key. This patch adds code to the create() function to check for the value of the ibmdb2i_create_index_option variable and, when appropriate, to generate a *HEX-based shadow index in DB2 for the primary key. Previously this behavior was limited to secondary indexes. Additionally, this patch restricts the creation of shadow indexes to cases in which a non-*HEX sort sequence is used, as the documentation for ibmdb2i_create_index_option describes. Previously, the shadow index would in some cases be created even when the MySQL-specific index used *HEX sorting, leading to redundant indexes. Finally, the code used to generate the list of fields for indexes and the code used to generate the SQL statement for the shadow indexes has been refactored into individual functions.
-
- 17 May, 2009 1 commit
-
-
Narayanan V authored
In order to better support the usage of IBMDB2I tables from within RPG programs, the storage engine should ensure that the RCDFMT name is consistent and predictable for DB2 tables. This patch appends a "RCDFMT <name>" clause to the CREATE TABLE statement that is passed to DB2. <name> is generated from the original name of the table itself. This ensures a consistent and deterministic mapping from the original table. For the sake of simplicity only the alpha-numeric characters are preserved when generating the new name, and these are upper-cased; other characters are replaced with an underscore (_). Following DB2 system identifier rules, the name always begins with an alpha-character and has a maximum of ten characters. If no usable characters are found in the table name, the name X is used.
-
- 29 Apr, 2009 1 commit
-
-
Narayanan V authored
The storage engine was not correctly handling the case in which rnd_pos is executed for a handler without a preceding rnd_next or index read operation. As a result, an unitialized file handle was sometimes being passed to the QMY_READ API. The fix clears the rrnAssocHandle at the beginning of each read operation and then checks to see whether it has been set to a valid handle value before attempting to use it in rnd_pos. If rrnAssocHandle has not been set by a previous read operation, rnd_pos instead falls back to the use of the currently active handle.
-
- 10 Apr, 2009 2 commits
-
-
Narayanan V authored
On IBM i 5.4, schemas with names that are longer than 8 characters and contain digits or an underscore cannot contain IBMDB2I tables, even though this should theoritically be possible if all alpha characters are uppercase. THe current patch fixes the IBMDB2I engine to allow digits and the underscore(_) to be used in schema names longer than 8 characters on IBM i 5.4.
-
Narayanan V authored
In some circumstances, when a table is created with the IBMDB2I engine, the CREATE TABLE statement will return successfully but the table will not exist. The current patch addresses the above issue and causes CREATE to fail and report and error to the user.
-
- 09 Mar, 2009 1 commit
-
-
Timothy Smith authored
-
- 15 Feb, 2009 1 commit
-
-
Timothy Smith authored
Modify plugins.m4 configuration framework so that plugins which are not built still get added to the source distribution during make dist. This came up now because we can only build ibmdb2i on i5/OS, and we can't bootstrap our source dist on that platform. The solution is to specify DIST_SUBDIRS containing all plugins, separate from SUBDIRS which contains the plugins which are actually built. This ibmdb2i code is from the ibmdb2i-ga3-src.zip file, with a patch to plug.in to disable the plugin if the PASE environment isn't available.
-