From 651095caaa131be52f735148a51c2c9135a800eb Mon Sep 17 00:00:00 2001 From: "serg@serg.mysql.com" <> Date: Sun, 15 Jul 2001 20:03:54 +0200 Subject: [PATCH 1/5] GEMINI manual removed --- Docs/manual.texi | 921 +---------------------------------------------- 1 file changed, 18 insertions(+), 903 deletions(-) diff --git a/Docs/manual.texi b/Docs/manual.texi index 1475219be19..bee4de54e30 100644 --- a/Docs/manual.texi +++ b/Docs/manual.texi @@ -498,7 +498,6 @@ MySQL Table Types * HEAP:: HEAP tables * InnoDB:: InnoDB tables * BDB:: BDB or Berkeley_db tables -* GEMINI:: GEMINI tables MyISAM Tables @@ -573,28 +572,6 @@ BDB or Berkeley_DB Tables * BDB portability:: Operating systems supported by @strong{BDB} * BDB errors:: Errors You May Get When Using BDB Tables -GEMINI Tables - -* GEMINI Overview:: -* Using GEMINI Tables:: - -GEMINI Overview - -* GEMINI Features:: -* GEMINI Concepts:: -* GEMINI Limitations:: - -Using GEMINI Tables - -* Startup Options:: -* Creating GEMINI Tables:: -* Backing Up GEMINI Tables:: -* Restoring GEMINI Tables:: -* Using Auto_Increment Columns With GEMINI Tables:: -* Performance Considerations:: -* Sample Configurations:: -* When To Use GEMINI Tables:: - MySQL Tutorial * Connecting-disconnecting:: Connecting to and disconnecting from the server @@ -4232,12 +4209,11 @@ phone back within 48 hours to discuss @code{MySQL} related issues. @cindex support, BDB Tables @cindex support, InnoDB Tables -@cindex support, GEMINI Tables @node Table handler support, , Telephone support, Support @subsection Support for other table handlers -To get support for @code{BDB} tables, @code{InnoDB} tables or -@code{GEMINI} tables you have to pay an additional 30% on the standard +To get support for @code{BDB} tables or @code{InnoDB} tables +you have to pay an additional 30% on the standard support price for each of the table handlers you would like to have support for. @@ -10074,8 +10050,8 @@ reload the grant tables. @cindex server, starting problems @cindex problems, starting the server -If you are going to use tables that support transactions (BDB, InnoDB or -Gemini), you should first create a my.cnf file and set startup options +If you are going to use tables that support transactions (BDB or InnoDB), +you should first create a my.cnf file and set startup options for the table types you plan to use. @xref{Table types}. Generally, you start the @code{mysqld} server in one of three ways: @@ -10227,9 +10203,6 @@ options. @xref{InnoDB start}. If you are using BDB (Berkeley DB) tables, you should familiarize yourself with the different BDB specific startup options. @xref{BDB start}. -If you are using Gemini tables, refer to the Gemini-specific startup options. -@xref{Using GEMINI Tables}. - @node Automatic start, Command-line options, Starting server, Post-installation @subsection Starting and Stopping MySQL Automatically @cindex starting, the server automatically @@ -11659,8 +11632,8 @@ concerned about transactions. For them transactions are not an issue. For those of our users who are concerned with or have wondered about transactions vis-a-vis @strong{MySQL}, there is a ``@strong{MySQL} way'' as we have outlined above. For those where safety is more -important than speed, we recommend them to use the @code{BDB}, -@code{GEMINI} or @code{InnoDB} tables for all their critical +important than speed, we recommend them to use the @code{BDB} +or @code{InnoDB} tables for all their critical data. @xref{Table types}. One final note: We are currently working on a safe replication schema @@ -11887,12 +11860,11 @@ Entry level SQL92. ODBC levels 0-2. @cindex tables, updating @cindex updating, tables @cindex @code{BDB} tables -@cindex @code{GEMINI} tables @cindex @code{InnoDB} tables The following mostly applies only for @code{ISAM}, @code{MyISAM}, and -@code{HEAP} tables. If you only use transaction-safe tables (@code{BDB}, -@code{GEMINI} or @code{InnoDB} tables) in an an update, you can do +@code{HEAP} tables. If you only use transaction-safe tables (@code{BDB} +or @code{InnoDB} tables) in an an update, you can do @code{COMMIT} and @code{ROLLBACK} also with @strong{MySQL}. @xref{COMMIT}. @@ -19074,7 +19046,7 @@ When you insert a value of @code{NULL} (recommended) or @code{0} into an If you delete the row containing the maximum value for an @code{AUTO_INCREMENT} column, the value will be reused with an -@code{ISAM}, @code{GEMINI} or @code{BDB} table but not with a +@code{ISAM} or @code{BDB} table but not with a @code{MyISAM} or @code{InnoDB} table. If you delete all rows in the table with @code{DELETE FROM table_name} (without a @code{WHERE}) in @code{AUTOCOMMIT} mode, the sequence starts over for all table types. @@ -19247,7 +19219,6 @@ The different table types are: @multitable @columnfractions .20 .80 @item BDB or Berkeley_db @tab Transaction-safe tables with page locking. @xref{BDB}. -@item GEMINI @tab Transaction-safe tables with row-level locking @xref{GEMINI}. @item HEAP @tab The data for this table is only stored in memory. @xref{HEAP}. @item ISAM @tab The original table handler. @xref{ISAM}. @item InnoDB @tab Transaction-safe tables with row locking. @xref{InnoDB}. @@ -22915,8 +22886,8 @@ By default, @strong{MySQL} runs in @code{autocommit} mode. This means that as soon as you execute an update, @strong{MySQL} will store the update on disk. -If you are using transactions safe tables (like @code{BDB}, -@code{InnoDB} or @code{GEMINI}), you can put @strong{MySQL} into +If you are using transactions safe tables (like @code{BDB} or +@code{InnoDB}), you can put @strong{MySQL} into non-@code{autocommit} mode with the following command: @example @@ -23798,7 +23769,6 @@ used them. @cindex table types, choosing @cindex @code{BDB} table type @cindex @code{Berkeley_db} table type -@cindex @code{GEMINI} table type @cindex @code{HEAP} table type @cindex @code{ISAM} table type @cindex @code{InnoDB} table type @@ -23811,8 +23781,8 @@ used them. As of @strong{MySQL} Version 3.23.6, you can choose between three basic table formats (@code{ISAM}, @code{HEAP} and @code{MyISAM}. Newer -@strong{MySQL} may support additional table type (@code{BDB}, -@code{GEMINI} or @code{InnoDB}), depending on how you compile it. +@strong{MySQL} may support additional table type (@code{BDB} +or @code{InnoDB}), depending on how you compile it. When you create a new table, you can tell @strong{MySQL} which table type it should use for the table. @strong{MySQL} will always create a @@ -23837,8 +23807,8 @@ You can convert tables between different types with the @code{ALTER TABLE} statement. @xref{ALTER TABLE, , @code{ALTER TABLE}}. Note that @strong{MySQL} supports two different kinds of -tables. Transaction-safe tables (@code{BDB}, @code{InnoDB} or -@code{GEMINI}) and not transaction-safe tables (@code{HEAP}, @code{ISAM}, +tables. Transaction-safe tables (@code{BDB} or @code{InnoDB}) +and not transaction-safe tables (@code{HEAP}, @code{ISAM}, @code{MERGE}, and @code{MyISAM}). Advantages of transaction-safe tables (TST): @@ -23880,7 +23850,6 @@ of both worlds. * HEAP:: HEAP tables * InnoDB:: InnoDB tables * BDB:: BDB or Berkeley_db tables -* GEMINI:: GEMINI tables @end menu @node MyISAM, MERGE, Table types, Table types @@ -25936,7 +25905,7 @@ Finland @cindex tables, @code{BDB} @cindex tables, @code{Berkeley DB} -@node BDB, GEMINI, InnoDB, Table types +@node BDB, , InnoDB, Table types @section BDB or Berkeley_DB Tables @menu @@ -26221,856 +26190,6 @@ not in @code{auto_commit} mode, until this problem is fixed (the fix is not trivial). @end itemize -@cindex GEMINI tables -@node GEMINI, , BDB, Table types -@section GEMINI Tables - -@cindex GEMINI tables, overview -@menu -* GEMINI Overview:: -* Using GEMINI Tables:: -@end menu - -@node GEMINI Overview, Using GEMINI Tables, GEMINI, GEMINI -@subsection GEMINI Overview - -GEMINI is currently not included in the @strong{MySQL} 3.23 distribution -because it's not to our knowledge an open source (GPL) product. - -@code{GEMINI} is a transaction-safe table handler for @strong{MySQL}. It -provides row-level locking, robust transaction support and reliable -crash recovery. It is targeted for databases that need to handle heavy -multi-user updates typical of transaction processing applications while -still providing excellent performance for read-intensive operations. The -@code{GEMINI} table type is developed and supported by NuSphere -Corporation (see @url{http://www.nusphere.com}). - -@code{GEMINI} provides full ACID transaction properties (Atomic, -Consistent, Independent, and Durable) with a programming model that -includes support for statement atomicity and all four standard isolation -levels (Read Uncommitted, Read Committed, Repeatable Read, and -Serializable) defined in the SQL standard. - -The @code{GEMINI} tables support row-level and table-level locking to -increase concurrency in applications and allow reading of tables without -locking for maximum concurrency in a heavy update environment. The -transaction, locking, and recovery mechanisms are tightly integrated to -eliminate unnecessary administration overhead. - -In general, if @code{GEMINI} tables are selected for an application, it -is recommended that all tables updated in the application be -@code{GEMINI} tables to provide well-defined system behavior. If -non-@code{GEMINI} tables are mixed into the application then, ACID -transaction properties cannot be maintained. While there are clearly -cases where mixing table types is appropriate, it should always be done -with careful consideration of the impact on transaction consistency and -recoverability needs of the application and underlying database. - -The @code{GEMINI} table type is derived from a successful commercial -database and uses the storage kernel technology tightly integrated with -@strong{MySQL} server. The basic @code{GEMINI} technology is in use by -millions of users worldwide in production environments today. This -maturity allows @code{GEMINI} tables to provide a solution for those -users who require transaction-based behavior as part of their -applications. - -The @code{GEMINI} table handler supports a configurable data cache that -allows a significant portion of any database to be maintained in memory -while still allowing durable updates. - -@cindex GEMINI tables, features -@menu -* GEMINI Features:: -* GEMINI Concepts:: -* GEMINI Limitations:: -@end menu - -@node GEMINI Features, GEMINI Concepts, GEMINI Overview, GEMINI Overview -@subsubsection GEMINI Features - -The following summarizes the major features provided by @code{GEMINI} -tables. - -@itemize @bullet -@item -Supports all optimization statistics used by the @strong{MySQL} optimizer -including table cardinality, index range estimates and multi-component -selectivity to insure optimal query performance. - -@item -Maintains exact cardinality information for each table so @code{SELECT -COUNT(*) FROM} table-name always returns an answer immediately. - -@item -Supports index-only queries; when index data is sufficient to resolve a -query no record data is read (for non character types). - -@item -@code{GEMINI} uses block based I/O for better performance. There is no -performance penalty for using @code{VARCHAR} fields. The maximum record size is -currently 32K. - -@item -The number of rows in a single @code{GEMINI} table can be 4 quintillion -(full use of 64 bits). - -@item -Individual tables can be as large as 16 petabytes. - -@item -Locking is done at a record or row level rather than at table level -unless table locks are explicitly requested. When a row is inserted into -a table, other rows can be updated, inserted or deleted without waiting -for the inserted row to be committed. - -@item -Provides durable transactions backed by a crash recovery mechanism that -returns the database to a known consistent state in the event of an -unexpected failure. - -@item -Support for all isolation levels and statement atomicity defined in the -SQL standard. - -@item -Reliable Master Replication; the master database can survive system -failure and recover all committed transactions. -@end itemize - -@cindex GEMINI tables, concepts -@node GEMINI Concepts, GEMINI Limitations, GEMINI Features, GEMINI Overview -@subsubsection GEMINI Concepts - -This section highlights some of the important concepts behind -@code{GEMINI} and the @code{GEMINI} programming model, including: - -@itemize @bullet -@item -ACID Transactions -@item -Transaction COMMIT/ROLLBACK -@item -Statement Atomicity -@item -Recovery -@item -Isolation Levels -@item -Row-Level Locking -@end itemize - -These features are described below. - -@cindex GEMINI tables, ACID transactions -@noindent -@strong{ACID Transactions} - -ACID in the context of transactions is an acronym which stands for -@emph{Atomicity}, @emph{Consistency}, @emph{Isolation}, @emph{Durability}. - -@multitable @columnfractions .25 .75 -@item @sc{Attribute} @tab @sc{Description} -@item -@strong{Atomicity} -@tab A transaction allows for the grouping of one or more changes to -tables and rows in the database to form an atomic or indivisible -operation. That is, either all of the changes occur or none of them -do. If for any reason the transaction cannot be completed, everything -this transaction changed can be restored to the state it was in prior to -the start of the transaction via a rollback operation. - -@item -@strong{Consistency} -@tab -Transactions always operate on a consistent view of the data and when -they end always leave the data in a consistent state. Data may be said to -be consistent as long as it conforms to a set of invariants, such as no -two rows in the customer table have the same customer ID and all orders -have an associated customer row. While a transaction executes, these -invariants may be violated, but no other transaction will be allowed to -see these inconsistencies, and all such inconsistencies will have been -eliminated by the time the transaction ends. - -@item -@strong{Isolation} -@tab To a given transaction, it should appear as though it is running -all by itself on the database. The effects of concurrently running -transactions are invisible to this transaction, and the effects of this -transaction are invisible to others until the transaction is committed. - -@item -@strong{Durability} -@tab Once a transaction is committed, its effects are guaranteed to -persist even in the event of subsequent system failures. Until the -transaction commits, not only are any changes made by that transaction -not durable, but are guaranteed not to persist in the face of a system -failures, as crash recovery will rollback their effects. -@end multitable - -@cindex GEMINI tables, COMMIT/ROLLBACK -@noindent -@strong{Transaction COMMIT/ROLLBACK} - -As stated above, a transaction is a group of work being done to -data. Unless otherwise directed, @strong{MySQL} considers each statement -a transaction in itself. Multiple updates can be accomplished by placing -them in a single statement, however they are limited to a single table. - -Applications tend to require more robust use of transaction -concepts. Take, for example, a system that processes an order: A row may -be inserted in an order table, additional rows may be added to an -order-line table, updates may be made to inventory tables, etc. It is -important that if the order completes, all the changes are made to all -the tables involved; likewise if the order fails, none of the changes to -the tables must occur. To facilitate this requirement, @strong{MySQL} -has syntax to start a transaction called @code{BEGIN WORK}. All -statements that occur after the @code{BEGIN WORK} statement are grouped -into a single transaction. The end of this transaction occurs when a -@code{COMMIT} or @code{ROLLBACK} statement is encountered. After the -@code{COMMIT} or @code{ROLLBACK} the system returns back to the behavior -before the @code{BEGIN WORK} statement was encountered where every -statement is a transaction. - -To permanently turn off the behavior where every statement is a -transaction, @strong{MySQL} added a variable called -@code{AUTOCOMMIT}. The @code{AUTOCOMMIT} variable can have two values, -@code{1} and @code{0}. The mode where every statement is a transaction -is when @code{AUTOCOMMIT} is set to @code{1} (@code{AUTOCOMMIT=1}). When -@code{AUTOCOMMIT} is set to @code{0} (@code{AUTOCOMMIT=0}), then every -statement is part of the same transaction until the transaction end by -either @code{COMMIT} or @code{ROLLBACK}. Once a transaction completes, a -new transaction is immediately started and the process repeats. - -Here is an example of the SQL statements that you may find in a typical -order: - -@example -BEGIN WORK; - INSERT INTO order VALUES ...; - INSERT INTO order-lines VALUES ...; - INSERT INTO order-lines VALUES ...; - INSERT INTO order-lines VALUES ...; - UPDATE inventory WHERE ...; -COMMIT; -@end example - -This example shows how to use the @code{BEGIN WORK} statement to start a -transaction. If the variable @code{AUTOCOMMIT} is set to @code{0}, then -a transaction would have been started already. In this case, the -@code{BEGIN WORK} commits the current transaction and starts a new one. - -@cindex GEMINI tables, statement atomicity -@noindent -@strong{Statement Atomicity} - -As mentioned above, when running with @code{AUTOCOMMIT} set to @code{1}, -each statement executes as a single transaction. When a statement has an -error, then all changes make by the statement must be -undone. Transactions support this behavior. Non-transaction safe table -handlers would have a partial statement update where some of the changes -from the statement would be contained in the database and other changes -from the statement would not. Work would need to be done to manually -recover from the error. - -@cindex GEMINI tables, recovery -@noindent -@strong{Recovery} - -Transactions are the basis for database recovery. Recovery is what -supports the Durability attribute of the ACID transaction. - -@code{GEMINI} uses a separate file called the Recovery Log located in -the @code{$DATADIR} directory named @code{gemini.rl}. This file -maintains the integrity of all the @code{GEMINI} tables. @code{GEMINI} -can not recover any data from non-@code{GEMINI} tables. In addition, the -@code{gemini.rl} file is used to rollback transactions in support of the -@code{ROLLBACK} statement. - -In the event of a system failure, the next time the @strong{MySQL} -server is started, @code{GEMINI} will automatically go through its -crash recovery process. The result of crash recovery is that all the -@code{GEMINI} tables will contain the latest changes made to them, and -all transactions that were open at the time of the crash will have been -rolled back. - -The @code{GEMINI} Recovery Log reuses space when it can. Space can be -reused when information in the Recovery Log is no longer needed for -crash recovery or rollback. - -@cindex GEMINI tables, isolation levels -@noindent -@strong{Isolation Levels} - -There are four isolation levels supported by @code{GEMINI}: - -@itemize @bullet -@item -READ UNCOMMITTED -@item -READ COMMITTED -@item -REPEATABLE READ -@item -SERIALIZABLE -@end itemize - -These isolation levels apply only to shared locks obtained by select -statements, excluding select for update. Statements that get exclusive -locks always retain those locks until the transaction commits or rolls -back. - -By default, @code{GEMINI} operates at the @code{READ COMMITTED} -level. You can override the default using the following command: - -@example -SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED | -READ COMMITTED | REPEATABLE READ | SERIALIZABLE ] -@end example - -If the @code{SESSION} qualifier used, the specified isolation level -persists for the entire session. If the @code{GLOBAL} qualifier is used, -the specified isolation level is applied to all new connections from -this point forward. Note that the specified isolation level will not -change the behavior for existing connections including the connection -that exectues the @code{SET GLOBAL TRANSACTION ISOLATION LEVEL} -statement. - -@multitable @columnfractions .30 .70 -@item @sc{Isolation Level} @tab @sc{Description} - -@item -@strong{READ UNCOMMITTED} -@tab Does not obtain any locks when reading rows. This means that if a -row is locked by another process in a transaction that has a more strict -isolation level, the @code{READ UNCOMMITTED} query will not wait until -the locks are released before reading the row. You will get an error if -attempt any updates while running at this isolation level. - -@item -@strong{READ COMMITTED} -@tab Locks the requested rows long enough to copy the row from the -database block to the client row buffer. If a @code{READ COMMITTED} -query finds that a row is locked exclusively by another process, it will -wait until either the row has been released, or the lock timeout value -has expired. - -@item -@strong{REPEATABLE READ} -@tab Locks all the rows needed to satisfy the query. These locks are -held until the transaction ends (commits or rolls back). If a -@code{REPEATABLE READ} query finds that a row is locked exclusively by -another process, it will wait until either the row has been released, or -the lock timeout value has expired. - -@item -@strong{SERIALIZABLE} -@tab Locks the table that contains the rows needed to satisfy the -query. This lock is held until the transaction ends (commits or rolls -back). If a @code{SERIALIZABLE} query finds that a row is exclusively -locked by another process, it will wait until either the row has been -released, or the lock timeout value has expired. -@end multitable - -The statements that get exclusive locks are @code{INSERT}, -@code{UPDATE}, @code{DELETE} and @code{SELECT ... FOR UPDATE}. Select -statements without the @code{FOR UPDATE} qualifier get shared locks -which allow other not ''for update'' select statements to read the same -rows but block anyone trying to update the row from accessing it. Rows -or tables with exclusive locks block all access to the row from other -transactions until the transaction ends. - -In general terms, the higher the Isolation level the more likelihood of -having concurrent locks and therefore lock conflicts. In such cases, -adjust the @code{-O gemini_lock_table_size} accordingly. - -@cindex GEMINI tables, row-level locking -@noindent -@strong{Row-Level Locking} - -@code{GEMINI} uses row locks, which allows high concurrency for requests -on the same table. - -In order to avoid lock table overflow, SQL statements that require -applying locks to a large number of rows should either be run at the -serializable isolation level or should be covered by a lock table -statement. - -Memory must be pre-allocated for the lock table. The mysqld server -startup option @code{-0 gemini_lock_table_size} can be used to adjust -the number of concurrent locks. - -@cindex GEMINI tables, limitations -@node GEMINI Limitations, , GEMINI Concepts, GEMINI Overview -@subsubsection GEMINI Limitations - -The following limitations are in effect for the current version of -@code{GEMINI}: - -@itemize @bullet -@item -@code{DROP DATABASE} does not work with @code{GEMINI} tables; instead, -drop all the tables in the database first, then drop the database. - -@item -Maximum number of @code{GEMINI} tables is 1012. - -@item -Maximum number of @code{GEMINI} files a server can manage is 1012. Each -table consumes one file; an additional file is consumed if the table has -any indexes defined on it. - -@item -Maximum size of BLOBs is 16MB. - -@item -@code{FULLTEXT} indexes are not supported with @code{GEMINI} tables. - -@item -There is no support for multi-component @code{AUTO_INCREMENT} fields -that provide alternating values at the component level. If you try to -create such a field, @code{GEMINI} will refuse. - -@item -@code{TEMPORARY TABLES} are not supported by @code{GEMINI}. The -statement @code{CREATE TEMPORARY TABLE ... TYPE=GEMINI} will generate -the response: @code{ERROR 1005: Can't create table '/tmp/#sqlxxxxx' -(errno: 0)}. - -@item -@code{FLUSH TABLES} has not been implemented with @code{GEMINI} tables. -@end itemize - -@cindex GEMINI tables, using -@node Using GEMINI Tables, , GEMINI Overview, GEMINI -@subsection Using GEMINI Tables - -This section explains the various startup options you can use with -@code{GEMINI} tables, how to backup @code{GEMINI} tables, some -performance considerations and sample configurations, and a brief -discussion of when to use @code{GEMINI} tables. - -Specifically, the topics covered in this section are: - -@itemize @bullet -@item -Startup Options -@item -Creating @code{GEMINI} Tables -@item -Backing Up @code{GEMINI} Tables -@item -Using Auto_Increment Columns With @code{GEMINI} Tables -@item -Performance Considerations -@item -Sample Configurations -@item -When To Use @code{GEMINI} Tables -@end itemize - -@cindex GEMINI tables, startup options -@menu -* Startup Options:: -* Creating GEMINI Tables:: -* Backing Up GEMINI Tables:: -* Restoring GEMINI Tables:: -* Using Auto_Increment Columns With GEMINI Tables:: -* Performance Considerations:: -* Sample Configurations:: -* When To Use GEMINI Tables:: -@end menu - -@node Startup Options, Creating GEMINI Tables, Using GEMINI Tables, Using GEMINI Tables -@subsubsection Startup Options - -The table below lists options to mysqld that can be used to change the -behavior of @code{GEMINI} tables. - -@multitable @columnfractions .40 .60 -@item @sc{Option} @tab @sc{Description} - -@item -@code{--default-table-type=gemini} -@tab Sets the default table handler to be @code{GEMINI}. All create -table statements will create @code{GEMINI} tables unless otherwise -specified with @code{TYPE=@var{table-type}}. As noted above, there is -currently a limitation with @code{TEMPORARY} tables using @code{GEMINI}. - -@item -@code{--gemini-flush-log-at-commit} -@tab Forces the recovery log buffers to be flushed after every -commit. This can have a serious performance penalty, so use with -caution. - -@item -@code{--gemini-recovery=FULL | NONE | FORCE} -@tab Sets the recovery mode. Default is @code{FULL}. @code{NONE} is -useful for performing repeatable batch operations because the updates -are not recorded in the recovery log. @code{FORCE} skips crash recovery -upon startup; this corrupts the database, and should be used in -emergencies only. - -@item -@code{--gemini-unbuffered-io} -@tab All database writes bypass the OS cache. This can provide a -performance boost on heavily updated systems where most of the dataset -being worked on is cached in memory with the @code{gemini_buffer_cache} -parameter. - -@item -@code{--O gemini_buffer_cache=size} -@tab Amount of memory to allocate for database buffers, including Index -and Record information. It is recommended that this number be 10% of the -total size of all @code{GEMINI} tables. Do not exceed amount of memory -on the system! - -@item -@code{--O gemini_connection_limit=#} -@tab Maximum number of connections to @code{GEMINI}; default is -@code{100}. Each connection consumes about 1K of memory. - -@item -@code{--O gemini_io_threads=#} -@tab Number of background I/O threads; default is @code{2}. Increase the -number when using @code{--gemini-unbuffered-io} - -@item -@code{--O gemini_lock_table_size=#} -@tab Sets the maximum number of concurrent locks; default is 4096. Using -@code{SET [ GLOBAL | SESSION ] TRANSACTION ISOLATION = ...} will -determine how long a program will hold row locks. - -@item -@code{--O gemini_lock_wait_timeout=seconds} -@tab Number of seconds to wait for record locks when performing queries; -default is 10 seconds. Using @code{SET [ GLOBAL | SESSION ] TRANSACTION -ISOLATION = ...} will determine how long a program will hold row locks. - -@item -@code{--skip-gemini} -@tab Do not use @code{GEMINI}. If you use @code{--skip-gemini}, @strong{MySQL} -will not initialize the @code{GEMINI} table handler, saving memory; you -cannot use @code{GEMINI} tables if you use @code{--skip-gemini}. - -@item -@code{--transaction-isolation=READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE} -@tab Sets the GLOBAL transaction isolation level for all users that -connect to the server; can be overridden with the SET ISOLATION LEVEL -statement. -@end multitable - -@cindex GEMINI tables, creating -@node Creating GEMINI Tables, Backing Up GEMINI Tables, Startup Options, Using GEMINI Tables -@subsubsection Creating GEMINI Tables - -@code{GEMINI} tables can be created by either using the @code{CREATE -TABLE} syntax or the @code{ALTER TABLE} syntax. - -@itemize @bullet -@item -The syntax for creating a @code{GEMINI} table is: - -@example -CREATE TABLE @var{table-name} (....) TYPE=GEMINI; -@end example - -@item -The syntax to convert a table to @code{GEMINI} is: - -@example -ALTER TABLE @var{table-name} TYPE=GEMINI; -@end example -@end itemize - -@xref{Tutorial}, for more information on how to create and use -@code{MySQL} tables. - -@cindex GEMINI tables, backing up -@node Backing Up GEMINI Tables, Restoring GEMINI Tables, Creating GEMINI Tables, Using GEMINI Tables -@subsubsection Backing Up GEMINI Tables - -@code{GEMINI} supports both @code{BACKUP TABLE} and @code{RESTORE TABLE} -syntax. To learn more about how to use @code{BACKUP} and @code{RESTORE}, -see @ref{BACKUP TABLE} and @ref{RESTORE TABLE}. - -To backup @code{GEMINI} tables outside of the @code{MySQL} environment, -you must first shut down the @code{MySQL} server. Once the server is -shut down, you can copy the files associated with @code{GEMINI} to a -different location. The files that make up the @code{GEMINI} table -handler are: - -@itemize @bullet -@item -All files associated with a table with a @code{.gmd} extention below the -@code{$DATADIR} directory. Such files include @code{@var{table}.gmd}, -@code{@var{table}.gmi}, and @code{@var{table}.frm} -@item -@code{gemini.db} in the @code{$DATADIR} directory -@item -@code{gemini.rl} in the @code{$DATADIR} directory -@item -@code{gemini.lg} in the @code{$DATADIR} directory -@end itemize - -All the @code{GEMINI} files must be copied together. You can not copy -just the @code{.gmi} and @code{.gmd} files to a different -@code{$DATADIR} and have them become part of a new database. You can -copy an entire @code{$DATADIR} directory to another location and start a -@strong{MySQL} server using the new @code{$DATADIR}. - -@cindex GEMINI tables, restoring -@node Restoring GEMINI Tables, Using Auto_Increment Columns With GEMINI Tables, Backing Up GEMINI Tables, Using GEMINI Tables -@subsubsection Restoring GEMINI Tables - -To restore @code{GEMINI} tables outside of the @code{MySQL} environment, -you must first shut down the @code{MySQL} server. Once the server is -shut down, you can remove all @code{GEMINI} files in the target -@code{$DATADIR} and then copy the files previously backed up into the -@code{$DATADIR} directory. - -As mentioned above, the files that make up the @code{GEMINI} table -handler are: - -@itemize @bullet -@item -All files associated with a table with a @code{.gmd} extention below the -@code{$DATADIR} directory. Such files include @code{@var{table}.gmd}, -@code{@var{table}.gmi}, and @code{@var{table}.frm} -@item -@code{gemini.db} in the @code{$DATADIR} directory -@item -@code{gemini.rl} in the @code{$DATADIR} directory -@item -@code{gemini.lg} in the @code{$DATADIR} directory -@end itemize - -When restoring a table, all the @code{GEMINI} files must be copied -together. You can not restore just the @code{.gmi} and @code{.gmd} -files. - -@cindex GEMINI tables, auto_increment -@node Using Auto_Increment Columns With GEMINI Tables, Performance Considerations, Restoring GEMINI Tables, Using GEMINI Tables -@subsubsection Using Auto_Increment Columns With GEMINI Tables - -As mentioned previously, @code{GEMINI} tables support row-level and -table-level locking to increase concurrency in applications and to allow -reading of tables without locking for maximum concurrency in heavy -update environments. This feature has several implications when working -with @code{auto_increment} tables. - -In @code{MySQL}, when a column is defined as an @code{auto_increment} -column, and a row is inserted into the table with a @code{NULL} for the -column, the @code{auto_increment} column is updated to be 1 higher than -the highest value in the column. - -With @code{MyISAM} tables, the @code{auto_increment} function is -implemented by looking in the index and finding the highest value and -adding 1 to it. This is possible because the entire @code{ISAM} table is -locked during the update period and the increment value is therefore -guaranteed to not be changing. - -With @code{GEMINI} tables, the @code{auto_increment} function is -implemented by maintaining a counter in a separate location from the -table data. Instead of looking at the highest value in the table index, -@code{GEMINI} tables look at this separately maintained counter. This -means that in a transactional model, unlike the bottleneck inherent in -the @code{MyISAM} approach, @code{GEMINI} users do @b{not} have to wait -until the transaction that added the last value either commits or -rollbacks before looking at the value. - -Two side-effects of the @code{GEMINI} implementation are: - -@itemize @bullet -@item -If an insert is done where the column with the @code{auto_increment} is -specified, and this specified value is the highest value, @code{MyISAM} -uses it as its @code{auto_increment} value, and every subsequent insert -is based on this. By contrast, @code{GEMINI} does not use this value, -but instead uses the value maintained in the separate @code{GEMINI} -counter location. - -@item -To set the counter to a specific value, you can use @code{SET -insert_id=#} and insert a new row in the table. However, as a general -rule, values should not be inserted into an @code{auto_increment} -column; the database manager should be maintaining this field, not the -application. @code{SET insert_id} is a recovery mechanism that should be -used in case of error only. -@end itemize - -Note that if you delete the row containing the maximum value for an -@code{auto_increment} column, the value will be reused with a -@code{GEMINI} table but not with a @code{MyISAM} table. - -See @ref{CREATE TABLE} for more information about creating -@code{auto_increment} columns. - -@cindex GEMINI tables, peformance considerations -@node Performance Considerations, Sample Configurations, Using Auto_Increment Columns With GEMINI Tables, Using GEMINI Tables -@subsubsection Performance Considerations - -In addition to designing the best possible application, configuration of -the data and the server startup parameters need to be considered. How -the hardware is being used can have a dramatic affect on how fast the -system will respond to queries. Disk Drives and Memory must both be -considered. - -@noindent -@strong{Disk Drives} - -For best performance, you want to spread the data out over as many disks -as possible. Using RAID 10 stripes work very well. If there are a lot of -updates then the recovery log (@code{gemini.rl}) should be on a -relatively quiet disk drive. - -To spread the data out without using RAID 10, you can do the following: - -@itemize @bullet -@item -Group all the tables into three categories: Heavy Use, Moderate Use, -Light Use. - -@item -Take the number of disk drives available and use a round-robin approach -to the three categories grouping the tables on a disk drive. The result -will be an equal distribution of Heavy/Moderate/Light tables assigned to -each disk drive. - -@item -Once the tables have been converted to @code{GEMINI} by using the -@code{ALTER TABLE TYPE=GEMINI} statements, move (@code{mv}) the -@code{.gmd} and @code{.gmi} files to a different disk drive and link -(@code{ln -s}) them back to the original directory where the @code{.frm} -file resides. - -@item -Finally, move the @code{gemini.rl} file to its quiet disk location and link -the file back to the @code{$DATADIR} directory. -@end itemize - -@noindent -@strong{Memory} - -The more data that can be placed in memory the faster the access to the -data. Figure out how large the @code{GEMINI} data is by adding up the -@code{.gmd} and @code{.gmi} file sizes. If you can, put at least 10% of -the data into memory. You allocate memory for the rows and indexes by -using the @code{gemini_buffer_cache} startup parameter. For example: - -@example -mysqld -O gemini_buffer_cache=800M -@end example - -@noindent -would allocate 800 MB of memory for the @code{GEMINI} buffer cache. - -@cindex GEMINI tables, sample configurations -@node Sample Configurations, When To Use GEMINI Tables, Performance Considerations, Using GEMINI Tables -@subsubsection Sample Configurations - -Based on the performance considerations above, we can look at some -examples for how to get the best performance out of the system when -using @code{GEMINI} tables. - -@multitable @columnfractions .30 .70 -@item @sc{Hardware} @tab @sc{Configuration} -@item -One CPU, 128MB memory, one disk drive -@tab Allocate 80MB of memory for reading and updating @code{GEMINI} -tables by starting the mysqld server with the following option: - -@example --O gemini_buffer_cache=80M -@end example - -@item -Two CPUs, 512MB memory, four disk drives -@tab Use RAID 10 to stripe the data across all available disks, or use -the method described in the performance considerations section, -above. Allocate 450MB of memory for reading/updating @code{GEMINI} -tables: - -@example --O gemini_buffer_cache=450M -@end example -@end multitable - -@cindex GEMINI tables, when to use -@node When To Use GEMINI Tables, , Sample Configurations, Using GEMINI Tables -@subsubsection When To Use GEMINI Tables - -Because the @code{GEMINI} table handler provides crash recovery and -transaction support, there is extra overhead that is not found in other -non-transaction safe table handlers. Here are some general guidelines -for when to employ @code{GEMINI} and when to use other non-transaction -safe tables (@code{NTST}). - -Note that in the following table, you could instead of GEMINI use -InnoDB or BDB tables. - -@multitable @columnfractions .30 .25 .45 -@item -@sc{Access Trends} @tab @sc{Table Type} @tab @sc{Reason} -@item -Read-only -@tab @code{NTST} -@tab Less overhead and faster -@item -Critical data -@tab @code{GEMINI} -@tab Crash recovery protection -@item -High concurrency -@tab @code{GEMINI} -@tab Row-level locking -@item -Heavy update -@tab @code{GEMINI} -@tab Row-level locking -@end multitable - -The table below shows how a typical application schema could be defined. - -@multitable @columnfractions .15 .30 .25 .30 -@item -@sc{Table} @tab @sc{Contents} @tab @sc{Table Type} @tab @sc{Reason} -@item -account -@tab Customer account data -@tab @code{GEMINI} -@tab Critical data, heavy update -@item -order -@tab Orders for a customer -@tab @code{GEMINI} -@tab Critical data, heavy update -@item -orderline -@tab Orderline detail for an order -@tab @code{GEMINI} -@tab Critical data, heavy update -@item -invdesc -@tab Inventory description -@tab @code{NTST} -@tab Read-only, frequent access -@item -salesrep -@tab Sales rep information -@tab @code{NTST} -@tab Infrequent update -@item -inventory -@tab Inventory information -@tab @code{GEMINI} -@tab High concurrency, critical data -@item -config -@tab System configuration -@tab @code{NTST} -@tab Read-only -@end multitable - @cindex tutorial @cindex terminal monitor, defined @cindex monitor, terminal @@ -44039,8 +43158,8 @@ included in the source. applications that need all speed they can get. The tables may be memory based,@code{HEAP} tables or disk based @code{MyISAM}. @xref{Table types}. @item -@strong{MySQL} has support for 3 different table handles that support -transactions (@code{BDB}, @code{InnoDB} and @code{Gemini}. Because +@strong{MySQL} has support for 2 different table handles that support +transactions (@code{BDB} and @code{InnoDB}}. Because every transaction engine performs differently under different conditions, this gives the application writer more options to find an optimal solution for his/her setup. @xref{Table types}. @@ -46584,10 +45703,6 @@ transaction-safe tables. @item @strong{InnoDB} A transaction-safe table handler that supports row level locking, and many Oracle-like features. -@c change "three" to "four" above when uncommenting this -@c @item Gemini -@c A transaction-safe, row-level locking table handler that supports many -@c features required in a mission-critical environment. @end table Note that only MyISAM is available in the standard binary distribution. From be05b70c0d6b7a0b229ce93efcc73ac8da8d56ed Mon Sep 17 00:00:00 2001 From: "heikki@donna.mysql.fi" <> Date: Thu, 19 Jul 2001 22:46:41 +0300 Subject: [PATCH 2/5] srv0srv.h Support raw disk as a data file srv0start.c Support raw disk as a data file srv0srv.c Support raw disk as a data file ha_innobase.cc Some error messages and support raw disk as a data file --- innobase/include/srv0srv.h | 16 ++++++- innobase/srv/srv0srv.c | 92 +++++++++++++++++++++++++++++++++++++- innobase/srv/srv0start.c | 29 ++++++++++-- sql/ha_innobase.cc | 45 ++++++++++++++++++- 4 files changed, 175 insertions(+), 7 deletions(-) diff --git a/innobase/include/srv0srv.h b/innobase/include/srv0srv.h index 26164e2ccdc..f80abda19c6 100644 --- a/innobase/include/srv0srv.h +++ b/innobase/include/srv0srv.h @@ -25,6 +25,7 @@ extern char* srv_arch_dir; extern ulint srv_n_data_files; extern char** srv_data_file_names; extern ulint* srv_data_file_sizes; +extern ulint* srv_data_file_is_raw_partition; extern char** srv_log_group_home_dirs; @@ -103,13 +104,26 @@ typedef struct srv_sys_struct srv_sys_t; /* The server system */ extern srv_sys_t* srv_sys; -/* Alternatives for fiel flush option in Unix; see the InnoDB manual about +/* Alternatives for file flush option in Unix; see the InnoDB manual about what these mean */ #define SRV_UNIX_FDATASYNC 1 #define SRV_UNIX_O_DSYNC 2 #define SRV_UNIX_LITTLESYNC 3 #define SRV_UNIX_NOSYNC 4 +/* Raw partition flags */ +#define SRV_OLD_RAW 1 +#define SRV_NEW_RAW 2 + +void +srv_mysql_thread_release(void); +/*==========================*/ +os_event_t +srv_mysql_thread_event_get(void); +void +srv_mysql_thread_slot_free( +/*==========================*/ + os_event_t event); /************************************************************************* Boots Innobase server. */ diff --git a/innobase/srv/srv0srv.c b/innobase/srv/srv0srv.c index 186ed1b8d56..028fae010d5 100644 --- a/innobase/srv/srv0srv.c +++ b/innobase/srv/srv0srv.c @@ -64,6 +64,8 @@ ulint srv_n_data_files = 0; char** srv_data_file_names = NULL; ulint* srv_data_file_sizes = NULL; /* size in database pages */ +ulint* srv_data_file_is_raw_partition = NULL; + char** srv_log_group_home_dirs = NULL; ulint srv_n_log_groups = ULINT_MAX; @@ -1490,6 +1492,7 @@ srv_init(void) slot = srv_mysql_table + i; slot->in_use = FALSE; slot->event = os_event_create(NULL); + slot->suspended = FALSE; ut_a(slot->event); } @@ -1658,6 +1661,7 @@ srv_suspend_mysql_thread( slot->thr = thr; os_event_reset(event); + slot->suspended = TRUE; slot->suspend_time = ut_time(); @@ -1689,6 +1693,27 @@ srv_suspend_mysql_thread( return(FALSE); } +os_event_t +srv_mysql_thread_event_get(void) +{ + srv_slot_t* slot; + os_event_t event; + + mutex_enter(&kernel_mutex); + + slot = srv_table_reserve_slot_for_mysql(); + + event = slot->event; + + os_event_reset(event); + + slot->suspended = TRUE; + + mutex_exit(&kernel_mutex); + + return(event); +} + /************************************************************************ Releases a MySQL OS thread waiting for a lock to be released, if the thread is already suspended. */ @@ -1712,6 +1737,7 @@ srv_release_mysql_thread_if_suspended( /* Found */ os_event_set(slot->event); + slot->suspended = FALSE; return; } @@ -1720,6 +1746,59 @@ srv_release_mysql_thread_if_suspended( /* not found */ } +void +srv_mysql_thread_release(void) +/*==========================*/ +{ + srv_slot_t* slot; + ulint i; + + mutex_enter(&kernel_mutex); + + for (i = 0; i < OS_THREAD_MAX_N; i++) { + + slot = srv_mysql_table + i; + + if (slot->in_use && slot->suspended) { + /* Found */ + slot->suspended = FALSE; + mutex_exit(&kernel_mutex); + + os_event_set(slot->event); + + return; + } + } + + ut_a(0); +} + +void +srv_mysql_thread_slot_free( +/*==========================*/ + os_event_t event) +{ + srv_slot_t* slot; + ulint i; + + mutex_enter(&kernel_mutex); + + for (i = 0; i < OS_THREAD_MAX_N; i++) { + + slot = srv_mysql_table + i; + + if (slot->in_use && slot->event == event) { + /* Found */ + slot->in_use = FALSE; + mutex_exit(&kernel_mutex); + + return; + } + } + + ut_a(0); +} + /************************************************************************* A thread which wakes up threads whose lock wait may have lasted too long. */ @@ -1907,6 +1986,11 @@ loop: } background_loop: + /* + sync_array_print_info(sync_primary_wait_array); + os_aio_print(); + buf_print_io(); + */ /* In this loop we run background operations while the server is quiet */ @@ -1967,9 +2051,15 @@ background_loop: } /* mem_print_new_info(); + */ - fsp_print(0); +/* fsp_print(0); */ + +/* fprintf(stderr, "Validating tablespace\n"); + fsp_validate(0); + fprintf(stderr, "Validation ok\n"); */ + #ifdef UNIV_SEARCH_PERF_STAT /* btr_search_print_info(); */ #endif diff --git a/innobase/srv/srv0start.c b/innobase/srv/srv0start.c index 80fafa37adf..16997e44349 100644 --- a/innobase/srv/srv0start.c +++ b/innobase/srv/srv0start.c @@ -330,10 +330,28 @@ open_or_create_data_files( sprintf(name, "%s%s", srv_data_home, srv_data_file_names[i]); - files[i] = os_file_create(name, OS_FILE_CREATE, + if (srv_data_file_is_raw_partition[i] == 0) { + + files[i] = os_file_create(name, OS_FILE_CREATE, OS_FILE_NORMAL, &ret); + } else if (srv_data_file_is_raw_partition[i] == SRV_OLD_RAW) { + ret = FALSE; + } else if (srv_data_file_is_raw_partition[i] == SRV_NEW_RAW) { + + files[i] = os_file_create( + name, OS_FILE_OPEN, OS_FILE_NORMAL, &ret); + + if (!ret) { + fprintf(stderr, + "InnoDB: Error in opening %s\n", name); + + return(DB_ERROR); + } + } + if (ret == FALSE) { - if (os_file_get_last_error() != + if (srv_data_file_is_raw_partition[i] == 0 + && os_file_get_last_error() != OS_FILE_ALREADY_EXISTS) { fprintf(stderr, "InnoDB: Error in creating or opening %s\n", @@ -364,8 +382,10 @@ open_or_create_data_files( ret = os_file_get_size(files[i], &size, &size_high); ut_a(ret); - if (size != UNIV_PAGE_SIZE * srv_data_file_sizes[i] - || size_high != 0) { + if (srv_data_file_is_raw_partition[i] == 0 + && (size != UNIV_PAGE_SIZE * srv_data_file_sizes[i] + || size_high != 0)) { + fprintf(stderr, "InnoDB: Error: data file %s is of different size\n" "InnoDB: than specified in the .cnf file!\n", name); @@ -722,6 +742,7 @@ innobase_start_or_create_for_mysql(void) mutex_exit(&(log_sys->mutex)); } + mutex_create(&row_mysql_thread_mutex); sess_sys_init_at_db_start(); if (create_new_db) { diff --git a/sql/ha_innobase.cc b/sql/ha_innobase.cc index bab5dc582e7..8ea700de789 100644 --- a/sql/ha_innobase.cc +++ b/sql/ha_innobase.cc @@ -287,6 +287,26 @@ innobase_parse_data_file_paths_and_sizes(void) str++; } + if (size >= 4096) { + fprintf(stderr, + "InnoDB: error: data file size must not be >= 4096M\n"); + return(FALSE); + } + + if (strlen(str) >= 6 + && *str == 'n' + && *(str + 1) == 'e' + && *(str + 2) == 'w') { + str += 3; + } + + if (strlen(str) >= 3 + && *str == 'r' + && *(str + 1) == 'a' + && *(str + 2) == 'w') { + str += 3; + } + if (size == 0) { return(FALSE); } @@ -301,8 +321,9 @@ innobase_parse_data_file_paths_and_sizes(void) } } - srv_data_file_names = (char**) ut_malloc(i * sizeof(void*)); + srv_data_file_names = (char**)ut_malloc(i * sizeof(void*)); srv_data_file_sizes = (ulint*)ut_malloc(i * sizeof(ulint)); + srv_data_file_is_raw_partition = (ulint*)ut_malloc(i * sizeof(ulint)); srv_n_data_files = i; @@ -337,6 +358,27 @@ innobase_parse_data_file_paths_and_sizes(void) str++; } + srv_data_file_is_raw_partition[i] = 0; + + if (strlen(str) >= 6 + && *str == 'n' + && *(str + 1) == 'e' + && *(str + 2) == 'w') { + str += 3; + srv_data_file_is_raw_partition[i] = SRV_NEW_RAW; + } + + if (strlen(str) >= 3 + && *str == 'r' + && *(str + 1) == 'a' + && *(str + 2) == 'w') { + str += 3; + + if (srv_data_file_is_raw_partition[i] == 0) { + srv_data_file_is_raw_partition[i] = SRV_OLD_RAW; + } + } + srv_data_file_names[i] = path; srv_data_file_sizes[i] = size; @@ -464,6 +506,7 @@ innobase_init(void) ret = innobase_parse_data_file_paths_and_sizes(); if (ret == FALSE) { + fprintf(stderr, "InnoDB: syntax error in innodb_data_file_path\n"); DBUG_RETURN(TRUE); } From b534cd660805b39686bc50540467cff934ea3211 Mon Sep 17 00:00:00 2001 From: "heikki@donna.mysql.fi" <> Date: Thu, 19 Jul 2001 23:00:42 +0300 Subject: [PATCH 3/5] srv0start.c Remove old code --- innobase/srv/srv0start.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/innobase/srv/srv0start.c b/innobase/srv/srv0start.c index 16997e44349..a343f2115e7 100644 --- a/innobase/srv/srv0start.c +++ b/innobase/srv/srv0start.c @@ -742,7 +742,7 @@ innobase_start_or_create_for_mysql(void) mutex_exit(&(log_sys->mutex)); } - mutex_create(&row_mysql_thread_mutex); + /* mutex_create(&row_mysql_thread_mutex); */ sess_sys_init_at_db_start(); if (create_new_db) { From 147c51b59b81da31935bacf5c6f7130bd9b9abba Mon Sep 17 00:00:00 2001 From: "heikki@donna.mysql.fi" <> Date: Fri, 20 Jul 2001 00:32:41 +0300 Subject: [PATCH 4/5] row0sel.c Disable a special join speed optimization until Peter Zaitsev's hang is tracked down --- innobase/row/row0sel.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/innobase/row/row0sel.c b/innobase/row/row0sel.c index 5599bb42a25..eef60c07af3 100644 --- a/innobase/row/row0sel.c +++ b/innobase/row/row0sel.c @@ -2537,7 +2537,10 @@ row_search_for_mysql( unique_search_from_clust_index = TRUE; - if (trx->mysql_n_tables_locked == 0 + /* Disable this optimization (hence FALSE below) until + the hang of Peter Zaitsev has been tracked down */ + + if (FALSE && trx->mysql_n_tables_locked == 0 && !prebuilt->sql_stat_start) { /* This is a SELECT query done as a consistent read, From fb1f570f8795147e1d554ea99d35d68314e09550 Mon Sep 17 00:00:00 2001 From: "serg@serg.mysql.com" <> Date: Wed, 25 Jul 2001 18:02:06 +0200 Subject: [PATCH 5/5] typo fixed --- Docs/manual.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Docs/manual.texi b/Docs/manual.texi index 6e342fe8b87..776bdc65482 100644 --- a/Docs/manual.texi +++ b/Docs/manual.texi @@ -43229,7 +43229,7 @@ applications that need all speed they can get. The tables may be memory based,@code{HEAP} tables or disk based @code{MyISAM}. @xref{Table types}. @item @strong{MySQL} has support for 2 different table handles that support -transactions (@code{BDB} and @code{InnoDB}}. Because +transactions (@code{BDB} and @code{InnoDB}). Because every transaction engine performs differently under different conditions, this gives the application writer more options to find an optimal solution for his/her setup. @xref{Table types}.