Misc. typos

Found via `codespell -i 3 -w --skip="./debian/po" -I ../mariadb-server-word-whitelist.txt  ./cmake/ ./debian/ ./Docs/ ./include/ ./man/ ./plugin/ ./strings/`

3 files changed, 18 insertions, 18 deletions

diff --git a/Docs/README-wsrep b/Docs/README-wsrep
index 422ec52f48a..6bb329e9396 100644
--- a/Docs/README-wsrep
+++ b/Docs/README-wsrep
@@ -366,7 +366,7 @@ wsrep_forced_binlog_format=none
    format, regardless of what the client session has specified in binlog_format.
    Valid choices for wsrep_forced_binlog_format are: ROW, STATEMENT, MIXED and
    special value NONE, meaning that there is no forced binlog format in effect.
-   This variable was intruduced to support STATEMENT format replication during
+   This variable was introduced to support STATEMENT format replication during
    rolling schema upgrade processing. However, in most cases ROW replication 
    is valid for asymmetrict schema replication.
 
diff --git a/Docs/myisam.txt b/Docs/myisam.txt
index ceb4ae7dc0b..db41fb911ca 100644
--- a/Docs/myisam.txt
+++ b/Docs/myisam.txt
@@ -95,7 +95,7 @@ Zero if the create is successful. Non-zero if an error occurs.
 
 HA_WRONG_CREATE_OPTION
  means that some of the arguments was wrong.
-appart from the above one can get any unix error that one can get from open(), write() or close().
+apart from the above one can get any unix error that one can get from open(), write() or close().
 
 #.#.4 Examples
 
@@ -169,7 +169,7 @@ The function parameter can be:
 HA_EXTRA_QUICK=1			Optimize for speed 
 HA_EXTRA_RESET=2			Reset database to after open 
 HA_EXTRA_CACHE=3			Cash record in HA_rrnd() 
-HA_EXTRA_NO_CACHE=4			End cacheing of records (def) 
+HA_EXTRA_NO_CACHE=4			End caching of records (def) 
 HA_EXTRA_NO_READCHECK=5		No readcheck on update 
 HA_EXTRA_READCHECK=6			Use readcheck (def) 
 HA_EXTRA_KEYREAD=7			Read only key to database 
@@ -335,7 +335,7 @@ int mi_rfirst(MI_INFO *mip , byte *buf, int inx)
 #.#.1 Description
 
 Reads the first row in the MyISAM file according to the specified index.
-If one want's to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
+If one wants to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
 
 mip is an MI_INFO pointer to the open handle.
 buf is the record buffer that will contain the row.
@@ -364,7 +364,7 @@ int mi_rkey(MI_INFO *mip, byte *buf, int inx, const byte *key, uint key_len, enu
 #.#.1 Description
 
 Reads the next row after the last row read, using the current index. 
-If one want's to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
+If one wants to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
 
 mip is an MI_INFO pointer to the open handle.
 buf is the record buffer that will contain the row.
@@ -397,7 +397,7 @@ int mi_rlast(MI_INFO *mip , byte *buf, int inx)
 #.#.1 Description
 
 Reads the last row in the MyISAM file according to the specified index.
-If one want's to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
+If one wants to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
 mip is an MI_INFO pointer to the open handle.
 buf is a pointer to the record buffer that will contain the row.
 Inx is the index (key) number, which must be the same as currently selected.
@@ -425,7 +425,7 @@ int mi_rnext(MI_INFO *mip , byte *buf, int inx )
 #.#.1 Description
 
 Reads the next row after the last row read, using the current index. 
-If one want's to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
+If one wants to read rows in physical sequences, then one should instead use mi_scan() or mi_rrnd().
 
 mip is an MI_INFO pointer to the open handle.
 buf is the record buffer that will contain the row.
@@ -520,7 +520,7 @@ int mi_rsame(MI_INFO *mip, byte *buf, int inx)
 
 Reads the current row to get its latest contents. This is useful to refresh the record buffer in case someone else has changed it.
 If inx is negative it reads by position. If inx is >= 0 it reads by key.
-With mi_rsame() one can switch to use any other index for the current row. This is good if you have a user application that lets the user do 'read-next' on a row.  In this case, if the user want's to start scanning on another index, one simply has to do a mi_rsame() on the new index to activate this.
+With mi_rsame() one can switch to use any other index for the current row. This is good if you have a user application that lets the user do 'read-next' on a row.  In this case, if the user wants to start scanning on another index, one simply has to do a mi_rsame() on the new index to activate this.
 
 mip is an MI_INFO pointer to the open handle.
 buf is the record buffer that will contain the row.
@@ -677,7 +677,7 @@ Zero if successful. Non-zero if an error occurred.
 HA_ERR_FOUND_DUPP_KEY
 A record already existed with a unique key same as this new record.
 HA_ERR_RECORD_FILE_FULL
-The error is given if you hit a system limit or if you try to create more rows in a table that you reserverd room for with mi_create().
+The error is given if you hit a system limit or if you try to create more rows in a table that you reserved room for with mi_create().
 ENOSPC
 The disk is full.
 EACCES
@@ -770,7 +770,7 @@ uint _mi_make_key( MI_INFO *mip, uint keynr, uchar *key, const char *record, my_
 Construct a key string for the given index, from the provided record buffer.
 ??? When packed records are used ...
 This is an internal function, not for use by applications. Monty says: "This can't be used to create an external key for an application from your record."
-See mi_make_application_key() for a similar function that is useable by applications.
+See mi_make_application_key() for a similar function that is usable by applications.
 
 The parameters are:
 A MI_INFO pointer mip.
@@ -872,7 +872,7 @@ HEAP tables only exists in memory so they are lost if `mysqld' is taken down or
 
 The *MySQL* internal HEAP tables uses 100% dynamic hashing without overflow areas and don't have problems with delete. 
 
-You can only access things by equality using a index (usually by the `=' operator) whith a heap table. 
+You can only access things by equality using a index (usually by the `=' operator) with a heap table. 
 The downside with HEAPS are: 
   1. You need enough extra memory for all HEAP tables that you want to use at the same time. 
   2. You can't search on a part of a index. 
diff --git a/Docs/sp-imp-spec.txt b/Docs/sp-imp-spec.txt
index 0526cc43f81..52389ea50f4 100644
--- a/Docs/sp-imp-spec.txt
+++ b/Docs/sp-imp-spec.txt
@@ -294,15 +294,15 @@
 
     - Detecting and parsing a FUNCTION invocation
 
-      The existance of UDFs are checked during the lexical analysis (in
+      The existence of UDFs are checked during the lexical analysis (in
       sql_lex.cc:find_keyword()). This has the drawback that they must
-      exist before they are refered to, which was ok before SPs existed,
+      exist before they are referred to, which was ok before SPs existed,
       but then it becomes a problem. The first implementation of SP FUNCTIONs
       will work the same way, but this should be fixed a.s.a.p. (This will
       required some reworking of the way UDFs are handled, which is why it's
       not done from the start.)
       For the time being, a FUNCTION is detected the same way, and returns
-      the token SP_FUNC. During the parsing we only check for the *existance*
+      the token SP_FUNC. During the parsing we only check for the *existence*
       of the function, we don't parse it, since wa can't call the parser
       recursively.
 
@@ -329,7 +329,7 @@
       of the mysql.proc table during a query execution, but this it not
       possible at the present.
 
-      So, the solution is to collect the names of the refered FUNCTIONs during
+      So, the solution is to collect the names of the referred FUNCTIONs during
       parsing in the lex.
       Then, before doing anything else in mysql_execute_command(), read all
       functions from the database an keep them in the THD, where the function
@@ -390,7 +390,7 @@
     a method in the THD's sp_rcontext (if there is one). If a handler is
     found, this is recorded in the context and the routine returns without
     sending the error message.
-    The exectution loop (sp_head::execute()) checks for this after each
+    The execution loop (sp_head::execute()) checks for this after each
     statement and invokes the handler that has been found. If several
     errors or warnings occurs during one statement, only the first is
     caught, the rest are ignored.
@@ -402,7 +402,7 @@
     Calling and returning from a CONTINUE handler poses some special
     problems. Since we need to return to the point after its invocation,
     we push the return location on a stack in the sp_rcontext (this is
-    done by the exectution loop). The handler then ends with a special
+    done by the execution loop). The handler then ends with a special
     instruction, sp_instr_hreturn, which returns to this location.
 
     CONTINUE handlers have one additional problem: They are parsed at
@@ -546,7 +546,7 @@
 
     Unfortunately, we cannot use alternative 1 for the time being, as most
     of the data structures to be cached (lex and items) are not reentrant
-    and thread-safe. (Things are modifed at execution, we have THD pointers
+    and thread-safe. (Things are modified at execution, we have THD pointers
     stored everywhere, etc.)
     This leaves us with alternative 2, one cache per thread; or actually
     two, since we keep FUNCTIONs and PROCEDUREs in separate caches.