Merge work:/home/bk/mysql-4.0

into serg.mysql.com:/usr/home/serg/Abk/mysql-4.0


Docs/manual.texi:
  Auto merged

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
@@ -4239,12 +4216,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.
 
@@ -10081,8 +10057,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:
@@ -10234,9 +10210,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
@@ -11666,8 +11639,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
@@ -11894,12 +11867,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}.
 
@@ -19081,7 +19053,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.
@@ -19254,7 +19226,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}.
@@ -22978,8 +22949,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
@@ -23862,7 +23833,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
@@ -23875,8 +23845,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
@@ -23901,8 +23871,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):
@@ -23944,7 +23914,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
@@ -26000,7 +25969,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
@@ -26285,856 +26254,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 <name> 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
@@ -44109,8 +43228,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}.
@@ -46654,10 +45773,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.

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. */
 

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,

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

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) {

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);
 	}