@@ -7704,6 +7704,11 @@ also work. There have been some problems with the @code{glibc} RPMs from
7704
7704
RedHat, so if you have problems, check whether or not there are any updates!
7705
7705
The @code{glibc} 2.0.7-19 and 2.0.7-29 RPMs are known to work.
7706
7706
7707
+ If you are using gcc 3.0 and above to compile MySQL, you must install
7708
+ the @code{libstdc++v3} library before compiling MySQL; If you don't do
7709
+ this you will get an error about a missing @code{__cxa_pure_virtual}
7710
+ symbol during linking!
7711
+
7707
7712
On some older Linux distributions, @code{configure} may produce an error
7708
7713
like this:
7709
7714
@@ -7757,7 +7762,7 @@ shell> CXX=gcc ./configure
7757
7762
@end example
7758
7763
7759
7764
If you are running gcc 3.0 and above, you can't use the above trick with
7760
- CXX=gcc, but you have to install libstd++ .
7765
+ setting to CXX=gcc .
7761
7766
7762
7767
@node Linux-SPARC, Linux-Alpha, Linux-x86, Linux
7763
7768
@subsubsection Linux SPARC Notes
@@ -9419,7 +9424,7 @@ work:
9419
9424
CC="cc -pthread"
9420
9425
CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host"
9421
9426
CXX="cxx -pthread"
9422
- CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host"
9427
+ CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host -noexceptions -nortti "
9423
9428
export CC CFLAGS CXX CXXFLAGS
9424
9429
./configure \
9425
9430
--prefix=/usr/local/mysql \
@@ -18622,36 +18627,103 @@ one extra connection for a client with the @code{Process_priv} privilege
18622
18627
to ensure that you should always be able to login and check the system
18623
18628
(assuming you are not giving this privilege to all your users).
18624
18629
18625
- Some frequently asked states in @code{mysqladmin processlist}
18626
-
18627
- @code{WAITING FOR TABLES}
18628
-
18629
- This means that the server is trying to get a lock of a
18630
- table(s). Usually this should happen very fast, unless there is some
18631
- problem around, such as another program holding table files open (e.g
18632
- @code{myisamchk}, anohter instance of @code{mysqld}), @code{mysqld} is
18633
- run without @code{--skip-locking}, table files are nfs mounted for
18634
- @code{mysqld}, etc.
18635
-
18636
- @code{OPENING TABLES}
18637
-
18638
- This simply means that the thread is trying to open a table. This also
18639
- should be very instant procedure, unless something prevents opening. An
18640
- @code{ALTER TABLE}, for example, can prevent opening a table until the
18641
- command is finished. If someone runs @code{FLUSH TABLES} simultaneously
18642
- with an @code{ALTER TABLE}, then all the threads that are trying to use
18643
- the table in @code{ALTER TABLE} query will be in this state.
18644
-
18645
- @code{CLOSING TABLES}
18646
-
18647
- Means that the thread is closing the tables that the thread was using.
18648
- If this is taking long, please check for the above for possible reasons
18649
- why it might be taking long.
18650
-
18651
- All of the above are usually very quick operations. If threads last
18652
- in any of these states for many seconds, there may be a problem around
18653
- that needs to be investigated. Check also that you have not run out
18654
- of harddisk space.
18630
+ Some frequently states in @code{mysqladmin processlist}
18631
+
18632
+ @itemize @bullet
18633
+ @item @code{Checking table}
18634
+ The thread doing an [automatic ?] checking of the table.
18635
+ @item @code{Closing tables}
18636
+ Means that the thread is flushing the changed table data to disk and
18637
+ closing the used tables. This should be a fast operation. If not, then
18638
+ you should check that you don't have a full disk or that the disk is not
18639
+ in very heavy use.
18640
+ @item @code{Copying to tmp table on disk}
18641
+ The temporary result set was larger than @code{tmp_table_size} and the
18642
+ thread is now changing the in memory based temporary table to a disk
18643
+ based one to save memory.
18644
+ @item @code{Creating tmp table}
18645
+ The thread is creating a temporary table to hold a part of the result for
18646
+ the query.
18647
+ @item @code{deleting from main table}
18648
+ When executing the first part of a multi-table delete and we are only
18649
+ deleting from the first table.
18650
+ @item @code{deleting from reference tables}
18651
+ When executing the second part of a multi-table delete and we are deleting
18652
+ the matched rows from the other tables.
18653
+ @item @code{Flushing tables}
18654
+ The thread is executing @code{FLUSH TABLES} and is waiting for all
18655
+ threads to close their tables.
18656
+ @item @code{Killed}
18657
+ Someone has sent a kill to the thread and it should abort next time it
18658
+ checks the kill flag. The flag is checked in each major loop in MySQL,
18659
+ but in some cases it may still take a short time for the thread to die.
18660
+ If the thread is locked by some other thread, the kill will take affect
18661
+ as soon as the other thread releases it's lock.
18662
+ @item @code{Sending data}
18663
+ The thread is processing rows for a @code{SELECT} statement and is
18664
+ also sending data to the client.
18665
+ @item @code{Sorting for group}
18666
+ The thread is doing a sort to satsify a @code{GROUP BY}.
18667
+ @item @code{Sorting for order}
18668
+ The thread is doing a sort to satsify a @code{ORDER BY}.
18669
+ @item @code{Opening tables}
18670
+ This simply means that the thread is trying to open a table. This is
18671
+ should be very fast procedure, unless something prevents opening. For
18672
+ example an @code{ALTER TABLE} or a @code{LOCK TABLE} can prevent opening
18673
+ a table until the command is finished.
18674
+ @item @code{Removing duplicates}
18675
+ The query was using @code{SELECT DISTINCT} in such a way that MySQL
18676
+ couldn't optimize that distinct away at an early stage. Because of this
18677
+ MySQL has to do an extra stage to remove all duplicated rows before
18678
+ sending the result to the client.
18679
+ @item @code{Reopen table}
18680
+ The thread got a lock for the table, but noticed after getting the lock
18681
+ that the underlying table structure changed. It has freed the lock,
18682
+ closed the table and is now trying to reopen it.
18683
+ @item @code{Repair by sorting}
18684
+ The repair code is using sorting to create indexes.
18685
+ @item @code{Repair with keycache}
18686
+ The repair code is using creating keys one by one through the key cache.
18687
+ This is much slower than @code{Repair by sorting}.
18688
+ @item @code{Searching rows for update}
18689
+ The thread is doing a first phase to find all matching rows before
18690
+ updating them. This has to be done if the @code{UPDATE} is changing
18691
+ the index that is used to find the involved rows.
18692
+ @item @code{Sleeping}
18693
+ The thread is wating for the client to send a new command to it.
18694
+ @item @code{System lock}
18695
+ The thread is waiting for getting to get a external system lock for the
18696
+ table. If you are not using multiple mysqld servers that are accessing
18697
+ the same tables, you can disable system locks with the
18698
+ @code{--skip-locking} option.
18699
+ @item @code{Upgrading lock}
18700
+ The @code{INSERT DELAYED} handler is trying to get a lock for the table
18701
+ to insert rows.
18702
+ @item @code{Updating}
18703
+ The thread is searching for rows to update and updating them.
18704
+ @item @code{User Lock}
18705
+ The thread is waiting on a @code{GET_LOCK()}.
18706
+ @item @code{Waiting for tables}
18707
+ The thread got a notification that the underlying structure for a table
18708
+ has changed and it needs to reopen the table to get the new structure.
18709
+ To be able to reopen the table it must however wait until all other
18710
+ threads have closed the table in question.
18711
+
18712
+ This notification happens if another thread has used @code{FLUSH TABLES}
18713
+ or one of the following commands on the table in question: @code{FLUSH
18714
+ TABLES table_name}, @code{ALTER TABLE}, @code{RENAME TABLE},
18715
+ @code{REPAIR TABLE}, @code{ANALYZE TABLE} or @code{OPTIMIZE TABLE}.
18716
+ @item @code{waiting for handler insert}
18717
+ The @code{INSERT DELAYED} handler has processed all inserts and are
18718
+ waiting to get new ones.
18719
+ @end itemize
18720
+
18721
+ Most states are very quick operations. If threads last in any of these
18722
+ states for many seconds, there may be a problem around that needs to be
18723
+ investigated.
18724
+
18725
+ There are some other states that are not mentioned above, but most of
18726
+ these are only useful to find bugs in @code{mysqld}.
18655
18727
18656
18728
@node SHOW GRANTS, SHOW CREATE TABLE, SHOW PROCESSLIST, SHOW
18657
18729
@subsubsection @code{SHOW GRANTS}
0 commit comments