| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\ |
|
| | | |
|
|\ \ \
| |/ / |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
* fix /etc/init.d/mysql to use log-basename for pid-filename
* fix mysqld_safe not to force logging-to-file when log-basename is specified
|
| |\ \ \
| | |/ /
| |/| /
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PERL "HOSTNAMES"
When building RPMs and using the "rpmbuild" automatic scanning for
Perl dependencies, it might interpret "use hostnames" in the
"mysql_config.pl" script usage comment as a Perl "use" statement.
And then makes the resulting RPMs depends on a non-existing module
Perl "hostnames". The comment was changed to prevent this.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Description: Certain operations using the client tool
'mysql\_setpermisson' which uses username of the format
"xxx-yyy" results in a syntax error.
Analysis: The user name variable ( $user ) was not quoted
properly in the 'mysql\_setpermission' script. As a result,
while granting user privileges for a user with username of
the format 'xxx-yyy', results in a syntax error.
Fix: The escape sequence has been applied for the user
variable in the script file.
Note: Test case is not added for this fix.
'mysql\_setpermission' executable resides in different
directories on pb2 machines and on local boxes. Hence the
test case cannot be made generic.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug#17959689: MAKE GCC AND CLANG GIVE CONSISTENT COMPILATION WARNINGS
Bug#18313717: ENABLE -WERROR IN MAINTANER MODE WHEN COMPILING WITH CLANG
Bug#18510941: REMOVE CMAKE WORKAROUNDS FOR OLDER VERSIONS OF OS X/XCODE
Backport from mysql-5.6 to mysql-5.5
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
5.6.15+, 5.7.3+
Follow-up patch. Removed unwanted code.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5.6.15+, 5.7.3+
Description: mysql_upgrade fails with below error,
when there are duplicate entries(like 'root'@'LOCALHOST'
and 'root'@'localhost') in mysql.user table.
ERROR 1062 (23000) at line 1140: Duplicate entry 'localhost-root' for key 'PRIMARY'
FATAL ERROR: Upgrade failed
Analysis: As part of the bug 12917151 fix we are
making all the hostnames as lower case hostnames.
So, this has been done by mysql_upgrade.
In case of above mentioned duplicate entries
mysql_upgrade tries to change hostname to lowercase.
Since there is already 'root'@'localhost' exists.
it is failing with "duplicate entry" error.
Fix: Since its a valid error failure. We are
making the error more verbose. So, that user will
delete the duplicate errors manually.
Along with existing error we are printing below
error as well.
ERROR 1644 (45000) at line 1153: Multiple accounts exist for @user_name, @host_name that differ only in Host lettercase; remove all except one of them
|
| | |
| | |
| | |
| | | |
Post-push patch. Changing file permission of "scripts/mysqlaccess.conf".
|
| | |
| | |
| | |
| | |
| | | |
Backporting patch committed for bug 18008907 to 5.5
and 5.6.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug#16415173 CRLF INSTEAD OF LF IN SQL-BENCH SCRIPTS
Correct perms and converts from Windows style to UNIX style line endings on some files.
Fix perms on installed ini files.
(MySQL 5.5 version)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug #18382225 MYSQL_CONFIG CAN'T HANDLE RELOCABLE PACKAGES THAT USES "LIB64" OR "-64" SUFFIX
'lib' is hardcoded into mysql_config, so 'cmake -DINSTALL_LIBDIR=lib64' will not work.
Use INSTALL_LIBDIR when generating mysql_config.
mysql_config may be renamed to e.g. mysql_config-32, fix the basedir pattern matching.
|
| | |
| | |
| | |
| | |
| | |
| | | |
'mysql_config --libs' outputs -L/path/to/library
on SunOS we also want it to output '-R/path/to/library'
in order to find libraries at runtime.
|
| | |
| | |
| | |
| | | |
to copyright header.
|
| | |
| | |
| | |
| | | |
Corrected how to find "resolveip"
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MYSQLBUG SCRIPT DURING INSTALLATION
Bug#68742 : Bug#16530527 : OBSOLETE BUGREPORT ADDRESSES
|
| | |\
| | | |
| | | |
| | | | |
UPPER CASE HOST NAME ANYMORE
Merging from mysql-5.1 to mysql-5.5
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
UPPER CASE HOST NAME ANYMORE
Description:
It is not possible to drop users with host names with upper case
letters in them. i.e DROP USER 'root'@'Tmp_Host_Name'; is failing
with error.
Analysis: Since the fix 11748570 we came up with lower case hostnames
as standard. But in the current bug the hostname is created by
mysql_install_db script is still having upper case hostnames.
So, if we have the hostname with upper case letters like(Tmp_Host_Name)
then we will have as it is stored in the mysql.user table.
In this case if use "'DROP USER 'root'@'Tmp_Host_Name';" it gives
error because we do compare with the lower case of hostname since the
11748570 fix.
Fix: We need to convert the hostname to lower case before storing into
the mysql.user table when we run the mysql_install_db script.
|
| | | | |
|
| | | |
| | | |
| | | | |
As this mysql_install_db.pl file has always generated lots of confusion on Windows. This fix will make sure to get it removed only from Windows
|
| | |\ \
| | | |/
| | | | |
Merging from 5.1 to 5.5
|
| | | |
| | | |
| | | |
| | | | |
Reverting the patch. Because this change is not to me made for GA versions.
|
| | |\ \
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem Description:
A mysqld_safe instance is started. An InnoDB crash recovery begins which takes
few seconds to complete. During this crash recovery process happening, another
mysqld_safe instance is started with the same server startup parameters. Since
the mysqld's pid file is absent during the crash recovery process the second
instance assumes there is no other process and tries to acquire a lock on the
ibdata files in the datadir. But this step fails and the 2nd instance keeps
retrying 100 times each with a delay of 1 second. Now after the 100 attempts,
the server goes down, but while going down it hits the mysqld_safe script's
cleanup section and without any check it blindly deletes the socket and pid
files. Since no lock is placed on the socket file, it gets deleted.
Solution:
We create a mysqld_safe.pid file in the datadir, which protects the presence
server instance resources by storing the mysqld_safe's process id in it. We
place a check if the mysqld_safe.pid file is existing in the datadir. If yes
then we check if the pid it contains is an active pid or not. If yes again,
then the scripts logs an error saying "A mysqld_safe instance is already
running". Otherwise it will log the present mysqld_safe's pid into the
mysqld_safe.pid file.
|
| | |\ \
| | | |/ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As current size limit of 'url' field of help_topic
table is no longer sufficient for the contents of
the fill_help_tables-5.1.sql. So, loading the contents
in the table might result in warning (or error with
stricter modes).
Updated the type for 'url' field of help_topic as well
as help_category tables from char(128) to text.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\ \
| | | |/ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
HOST HAS '_' IN THE HOSTNAME
Problem:
=======
'_' and '%' are treated as a wildcards by the ACL code and
this is documented in the manual. The problem with
mysql_install_db is that it does not take this into account
when creating the initial GRANT tables:
--- cut ---
REPLACE INTO tmp_user SELECT @current_hostname,'root','','Y',
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','',
0,0,0,0 FROM dual WHERE LOWER( @current_hostname) != 'localhost';
--- cut ---
If @current_hostname contains any wildcard characters, then
a wildcard entry will be defined for the 'root' user,
which is a flaw.
Analysis:
========
As per the bug description when we have a hostname with a
wildcard character in it, it allows clients from several other
hosts with similar name pattern to connect to the server as root.
For example, if the hostname is like 'host_.com' then the same
name is logged in mysql.user table. This allows 'root' users
from other hosts like 'host1.com', 'host2.com' ... to connect
to the server as root user.
While creating the intial GRANT tables we do not have a check
for wildcard characters in hostname.
Fix:
===
As part of fix escape character "\" is added before wildcard
character to make it a plain character, so that the one and
only host with the exact name will be able to connect to the
server.
|
| | |\ \
| | | |/ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some shell interpreters do not support '-e' test
primary to construct conditions.
man test 1 (on S10)
...skip...
-e file True if file exists. (Not available in sh.)
...skip...
Hence, check for the existence of a file using
'-e' might result in a syntax error on such
shell programs.
Fixed by replacing it by '-f'.
|
| | | |\ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Bug #14181049: MYSQL_INSTALL_DB.PL CREATES EMPTY SYSTEM TABLES FOR MYSQL
The script is different from what's used on unixes.
It was not playing the table insertion script (mysql_system_tables_data.sql),
although it was checking for the presence of this script.
Fixed by re-enabling the lookup for this file and replaying it at bootstrap
time. Note that on the Unixes "SELECT @@hostname" does return a fully qualified
name, whereas on Windows it returns only a hostname.
So by default we're filtering records in the mysql.user table until we ensure
this is fixed.
The change was coded in 5.5 by Georgi Kodinov <Georgi.Kodinov@Oracle.com>
|
| | |\ \ \
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
mysqld_safe script did not heed MySQL specific environment variable
$UMASK, leading to divergent behavior between mysqld and mysqld_safe.
Patch adds an approximation of mysqld's behavior to mysqld_safe,
within the bounds dictated by attempt to have mysqld_safe run on
even the most basic of shells (proper '70s sh, not just bash
with a fancy symlink).
Patch also adds approximation of said behavior to mysqld_multi
(in perl).
(backport)
manual merge
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mysqld_safe script did not heed MySQL specific environment variable
$UMASK, leading to divergent behavior between mysqld and mysqld_safe.
Patch adds an approximation of mysqld's behavior to mysqld_safe,
within the bounds dictated by attempt to have mysqld_safe run on
even the most basic of shells (proper '70s sh, not just bash
with a fancy symlink).
Patch also adds approximation of said behavior to mysqld_multi
(in perl).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
TO DEFAULT IGNOR
The test in mysqld_safe for the presence of the --plugin-dir and assigning a default
value to it were performed before the actual argument parsing.
This is wrong, as PLUGIN_DIR mysqld_safe code also uses MY_BASEDIR_VERSION to
look for version specific plugin directory if present.
Fixed by moving the PLUGIN_DIR logic after the parse_arguments() call.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The script is different from what's used on unixes.
It was not playing the table insertion script (mysql_system_tables_data.sql),
although it was checking for the presence of this script.
Fixed by re-enabling the lookup for this file and replaying it at bootstrap
time. Note that on the Unixes "SELECT @@hostname" does return a fully qualified
name, whereas on Windows it returns only a hostname.
So by default we're filtering records in the mysql.user table until we ensure
this is fixed.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem description:
mysqlhotcopy fails if a view presents in the database.
Analysis:
Before 5.5 'FLUSH TABLES <tbl_name> ... WITH READ LOCK' will able
to get lock for all tables (i.e. base tables and view tables).
In 5.5 onwards 'FLUSH TABLES <tbl_name> ... WITH READ LOCK' for
'view tables' will not work, because taking flush locks on view
tables is not valid.
Fix:
Take flush lock for 'base tables' and read lock for 'view table'
separately.
Note: most of the patch has been backported from bug#13006947's patch
|
| | |\ \
| | | |/ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
WORK + SAVES ROOT PASSWORD TO DISK!
The secure installation scripts connect to the
server by storing the password in a temporary
option file. Now, if the script gets killed or
fails for some reason, the removal of the option
file may not take place.
This patch introduces following enhancements :
* (.sh) Made sure that cleanup happens at every
call to 'exit 1'. This is performed implicitly
by END{} in pl.in.
* (.pl.in) Added a warning in case unlink fails
to delete the option/query files.
* (.sh/.pl.in) Added more signals to the signal
handler list. SIG# 1, 3, 6, 15
|
| | |\ \
| | | |/ |
|
| | | |\ |
|