MySQL Information Sources
=========================
MySQL Mailing Lists
-------------------
to the
list. You will also be able to send your own questions and answers to
the list.
The MySQL Mailing Lists
.......................
To subscribe to or unsubscribe from any of the mailing lists described
in this section, visit `http://lists.mysql.com/'. Please *do not* send
messages about subscribing or unsubscribing to any of the mailing
lists, because such messages are distributed automatically to thousands
of other users.
Your local site may have many subscribers to a MySQL mailing list. If
so, the site may have a local mailing list, so that messages sent from
`lists.mysql.com' to your site are propagated to the local list. In
such cases, please contact your system administrator to be added to or
dropped from the local MySQL list.
If you wish to have traffic for a mailing list go to a separate mailbox
in your mail program, set up a filter based on the message headers.
You can use either the `List-ID:' or `Delivered-To:' headers to identify
list messages.
The MySQL mailing lists are as follows:
``announce''
This list is for announcements of new versions of MySQL and related
programs. This is a low-volume list to which all MySQL users
should subscribe.
not get an answer.
``mysql-digest''
This is the `mysql' list in digest form. Subscribing to this list
means you will get all list messages, sent as one large mail
message once a day.
``bugs''
This list will be of interest to you if you want to stay informed
about issues reported since the last release of `MySQL' or if you
want to be actively involved in the process of bug hunting and
fixing. *Note Bug reports::.
``bugs-digest''
This is the `bugs' list in digest form.
``internals''
This list is for people who work on the MySQL code. This is also
the forum for discussions on MySQL development and post patches.
``internals-digest''
This is the `internals' list in digest form.
``mysqldoc''
This list is for people who work on the MySQL documentation:
people from MySQL AB, translators, and other community members.
``mysqldoc-digest''
This is the `mysqldoc' list in digest form.
``benchmarks''
This list is for anyone interested in performance issues.
Discussions concentrate on database performance (not limited to
MySQL) but also include broader categories such as performance of
the kernel, file system, disk system, and so on.
``benchmarks-digest''
This is the `benchmarks' list in digest form.
``packagers''
This list is for discussions on packaging and distributing MySQL.
This is the forum used by distribution maintainers to exchange
ideas on packaging MySQL and on ensuring that MySQL looks and
feels as similar as possible on all supported platforms and
operating systems.
``packagers-digest''
This is the `packagers' list in digest form.
``java''
This list is for discussions about the MySQL server and Java.It is
mostly used to discuss JDBC drivers, including MySQL Connector/J.
``java-digest''
This is the `java' list in digest form.
``win32''
This list is for all things concerning the MySQL software on
Microsoft operating systems, such as Windows 9x/Me/NT/2000/XP.
``win32-digest''
This is the `win32' list in digest form.
``myodbc''
This list is for all things concerning connecting to the MySQL
server with ODBC.
``myodbc-digest''
This is the `myodbc' list in digest form.
``mysqlcc''
This list is for all things concerning the `MySQL Control Center'
graphical client.
``mysqlcc-digest''
This is the `mysqlcc' list in digest form.
``plusplus''
This list is for all things concerning programming with the C++
API to MySQL.
``plusplus-digest''
This is the `plusplus' list in digest form.
``msql-mysql-modules''
This list is for all things concerning the Perl support for MySQL
with `msql-mysql-modules', which is now named `DBD-mysql'.
``msql-mysql-modules-digest''
This is the `msql-mysql-modules' list in digest form.
The following table shows some MySQL mailing lists in languages other
than English. These lists are not operated by MySQL AB, so we can't
guarantee their quality.
` A French mailing list'
` A Korean mailing list'
E-mail `subscribe mysql your@e-mail.address' to this list.
` A German mailing list'
E-mail `subscribe mysql-de your@e-mail.address' to this list. You
can find information about this mailing list at
`http://www.4t2.com/mysql/'.
` A Portuguese mailing list'
E-mail `subscribe mysql-br your@e-mail.address' to this list.
` A Spanish mailing list'
E-mail `subscribe mysql your@e-mail.address' to this list.
Asking Questions or Reporting Bugs
..................................
Before posting a bug report or question, please do the following:
change history appendix
(`http://www.mysql.com/doc/en/News.html') can be particularly
useful since it is quite possible that a newer version already
contains a solution to your problem.
* Search in the bugs database at `http://bugs.mysql.com/' to see
whether the bug has already been reported/solved.
at
`http://www.mysql.com/'.
If you can't find an answer in the manual or the archives, check with
your local MySQL expert. If you still can't find an answer to your
question, please follow the guidelines on sending mail to a MySQL
mailing list, outlined in the next section, before contacting us.
How to Report Bugs or Problems
..............................
Our bugs database is public, and can be browsed and searched by anyone
at `http://bugs.mysql.com/'. If you log into the system, you will also
be able to enter new reports.
Writing a good bug report takes patience, but doing it right the first
time saves time both for us and for yourself. A good bug report,
containing a full test case for the bug, makes it very likely that we
will fix the bug in the next release. This section will help you write
your report correctly so that you don't waste your time doing things
that may not help us much or at all.
We encourage everyone to use the `mysqlbug' script to generate a bug
report (or a report about any problem). `mysqlbug' can be found in the
`scripts' directory (source distribution) and in the `bin' directory
under your MySQL installation directory (binary distribution). If you
are unable to use `mysqlbug' (for instance, if you are running on
Windows), it is still vital that you include all the necessary
information noted in this section (most importantly a description of
the operating system and the MySQL version).
The `mysqlbug' script helps you generate a report by determining much
of the following information automatically, but if something important
is missing, please include it with your message. Please read this
section carefully and make sure that all the information described here
is included in your report.
Preferably, you should test the problem using the latest production or
development version of MySQL Server before posting. Anyone should be
able to repeat the bug by just using '`mysql test < script'' on the
included test case or run the shell or Perl script that is included in
the bug report.
All bugs posted in the bugs database at `http://bugs.mysql.com/' will
be corrected or documented in the next MySQL release. If only minor
code changes are needed to correct a problem, we will also post a patch
that fixes the problem.
The normal place to report bugs is `http://bugs.mysql.com/'.
If you have found a sensitive security bug in MySQL, please send an
e-mail to .
If you have a repeatable bug report, please report this into the bugs
database at `http://bugs.mysql.com/'. Note that even in this case it's
good to run the `mysqlbug' script first to find information about your
system. Any bug that we are able to repeat has a high chance of being
fixed in the next MySQL release.
To report other problems, you can use one of the MySQL mailing lists.
Remember that it is possible for us to respond to a message containing
too much information, but not to one containing too little. People
often omit facts because they think they know the cause of a problem
and assume that some details don't matter. A good principle is: if you
are in doubt about stating something, state it. It is a thousand times
faster and less troublesome to write a couple of lines more in your
report than to be forced to ask again and wait for the answer because
you didn't include enough information the first time.
The most common errors made in bug reports are (a) not including the
version number of the MySQL distribution used and (b) not fully
describing the platform on which the MySQL server is installed
(including the platform type and version number). This is highly
relevant information, and in 99 cases out of 100 the bug report is
useless without it. Very often we get questions like, "Why doesn't
this work for me?" Then we find that the feature requested wasn't
implemented in that MySQL version, or that a bug described in a report
has already been fixed in newer MySQL versions. Sometimes the error is
platform-dependent; in such cases, it is next to impossible for us to
fix anything without knowing the operating system and the version
number of the platform.
Remember also to provide information about your compiler, if it is
related to the problem. Often people find bugs in compilers and think
the problem is MySQL-related. Most compilers are under development all
the time and become better version by version. To determine whether
your problem depends on your compiler, we need to know what compiler
you use. Note that every compiling problem should be regarded as a bug
and reported accordingly.
It is most helpful when a good description of the problem is included
in the bug report. That is, give a good example of all the things you
did that led to the problem and describe, in exact detail, the problem
itself. The best reports are those that include a full example showing
how to reproduce the bug or problem. *Note Reproduceable test case::.
reported
exactly matches the one that the program produces. (Even the case
should be observed.) You should never try to remember what the error
message was; instead, copy and paste the entire message into your
report.
If you have a problem with MyODBC, please try to generate a MyODBC
trace file and send it with your report. *Note MyODBC bug report::.
Please remember that many of the people who will read your report will
do so using an 80-column display. When generating reports or examples
using the `mysql' command-line tool, you should therefore use the
`--vertical' option (or the `\G' statement terminator) for output that
would exceed the available width for such a display (for example, with
the `EXPLAIN SELECT' statement; see the example later in this section).
Please include the following information in your report:
can be
found in the `bin' directory under your MySQL installation
directory.
* The manufacturer and model of the machine on which you experience
the problem.
* The operating system name and version. For most operating
systems, you can get this information by executing the Unix
command `uname -a'. If you work with Windows, you can usually get
the name and version number by double-clicking your "My Computer"
icon and pulling down the "Help/About Windows" menu.
* Sometimes the amount of memory (real and virtual) is relevant. If
in doubt, include these values.
* If you are using a source distribution of the MySQL software, the
name and version number of the compiler used is needed. If you
have a binary distribution, the distribution name is needed.
* If the problem occurs during compilation, include the exact error
message(s) and also a few lines of context around the offending
code in the file where the error occurrs.
* If `mysqld' died, you should also report the query that crashed
`mysqld'. You can usually find this out by running `mysqld' with
logging enabled. *Note Using log files::.
about
any table in a database. The information will help us create a
situation matching the one you have.
* For speed-related bugs or problems with `SELECT' statements, you
should always include the output of `EXPLAIN SELECT ...', and at
least the number of rows that the `SELECT' statement produces. You
should also include the output from `SHOW CREATE TABLE tbl_name'
for each involved table. The more information you give about your
situation, the more likely it is that someone can help you. The
following is an example of a very good bug report (it should of
course be posted with the `mysqlbug' script).
Example run using the `mysql' command-line tool (note the use of
the `\G' statement terminator for statements whose output width
would otherwise exceed that of an 80-column display device):
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
[Назад] [Содержание] [Вперед]
| Главная |