include/mysql_com.h:
Auto merged
libmysqld/lib_sql.cc:
Auto merged
myisam/mi_check.c:
Auto merged
scripts/mysql_install_db.sh:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/protocol.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/share/czech/errmsg.txt:
Auto merged
sql/share/romanian/errmsg.txt:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_select.cc:
Auto merged
Otherwise, if the previous run ended with a crash, and the PID was 1234,
and you have rebooted the machine and the new PID is 99 then in the PID
file you will have 9934.
Note: users of mysqld_safe did not have the problem because this script
deletes the PID file before starting mysqld.
The constructor of Rotate_log_event used when we are rotating our binlog or
relay log, should not assume that there is a nonzero THD available.
For example, when we are reacting to SIGHUP, the THD is 0.
In fact we don't need to use the THD in this constructor;
we can do like for Stop_log_event, and use the minimal Log_event
constructor.
If we were allowed to put Unix-specific commands in the testsuite,
I'd add a test for this (<sigh>).
sql/log.cc:
A comment to warn that thd can be 0.
The part about LOG_EVENT_FORCED_ROTATE_F is just to avoid segfault;
this flag is already removed in 4.1 anyway.
sql/log_event.cc:
A comment.
sql/log_event.h:
The constructor of Rotate_log_event used when we are rotating our binlog or
relay log, should not assume that there is a nonzero THD available.
For example, when we are reacting to SIGHUP, the THD is 0.
In fact we don't need to use the THD in this constructor;
we can do like for Stop_log_event, and use the minimal Log_event
constructor.
This fixes BUG#2045
"Sending SIGHUP to mysqld crashes it if running with --log-bin"
- postinstall of the Mac OS X PKG failed as a parameter for
mysql_install_db was changed for MySQL 4.1
- postinstall of the Server RPM failed as mysql_create_system_tables was
missing from the file list
support-files/MacOSX/postinstall.sh:
- Fix parameter for mysql_install_db (it was changed from -IN-RPM to --rpm
in the 4.1 tree)
support-files/mysql.spec.sh:
- Added missing file mysql_create_system_tables to the server subpackage
mysql-test/r/func_time.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql/item_create.cc:
Auto merged
sql/item_create.h:
Auto merged
sql/lex.h:
Auto merged
into mysql.com:/my/mysql-4.1
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
strings/ctype-big5.c:
Auto merged
strings/ctype-euc_kr.c:
Auto merged
strings/ctype-gb2312.c:
Auto merged
strings/ctype-gbk.c:
Auto merged
strings/ctype-sjis.c:
Auto merged
strings/ctype-ujis.c:
Auto merged
sql/protocol.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/slave.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_show.cc:
Auto merged
to mysqld that is executed for all new connections.
(Similar to the client command: mysql_options(... MYSQL_INIT_COMMAND ...).
sql/mysql_priv.h:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/mysqld.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/protocol.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/set_var.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/slave.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/sql_class.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/sql_class.h:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/sql_parse.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
sql/sql_show.cc:
Task ID 499:Add a new settable string variable(init_connect, init_slave)
to mysqld that is executed for all new connections.
New formats added for 'week()' function and 'default_week_format' option(4 - 7).
Next formats is supported now:
*Value* *Meaning*
`0' Week starts on Sunday; First Sunday of the year starts week 1.
Week() returns 0-53.
`1' Week starts on Monday; Weeks numbered according to ISO 8601:1988.
Week() returns 0-53.
`2' Week starts on Sunday; First Sunday of the year starts week 1.
Week() returns 1-53.
`3' Week starts on Monday; Weeks numbered according to ISO 8601:1988.
Week() returns 1-53.
`4' Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
Week() returns 0-53.
`5' Week starts on Monday; First Monday of the year starts week 1.
Week() returns 0-53.
`6' Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
Week() returns 1-53.
`7' Week starts on Monday; First Monday of the year starts week 1.
Week() returns 1-53.
mysql-test/r/func_time.result:
Test for 'default_week_format' option and 'week' function
mysql-test/t/func_time.test:
Test for 'default_week_format' option and 'week' function
sql/item_timefunc.cc:
WL#1175 more default_week_formats for iso compatibility
sql/mysql_priv.h:
WL#1175 more default_week_formats for iso compatibility
sql/mysqld.cc:
WL#1175 more default_week_formats for iso compatibility
sql/time.cc:
WL#1175 more default_week_formats for iso compatibility
(isn't it obvious ?)
mysys/charset.c:
all charsets support my_mbcharlen - no need to protect it with use_mb()
sql/sql_load.cc:
all charsets support my_mbcharlen - no need to protect it with use_mb()
table definition crashed), and recursive calls.
mysql-test/r/sp.result:
New test cases for BUG#1653 and recursive calls.
mysql-test/t/sp.test:
New test cases for BUG#1653 and recursive calls.
This bug happens under Windows & Embedded server
Reason is that pthread_self() always returns NULL in this case.
This confuses thr_lock function and it doesn't stop
thread inserting in the write-locked table.
Global problem is that there's no way under Windows to get
unique thread handle for working thread.
Monty made a workaround for server - we store the thread's handle
we get when we create thread in the thread-specific variable.
This doesn't work with the embedded library for we don't control
thread creation there.
I added code that sets CurrentThreadId as the pthread_self
for the embedded library.
It seems to solve problem because it's unique and we don't use
pthread_self as a parameter for thread functions in embedded library.
mysys/my_thr_init.c:
setting of tmp->thread_self added
BitKeeper/etc/ignore:
auto-union
BitKeeper/etc/logging_ok:
auto-union
myisam/mi_check.c:
Auto merged
myisam/myisamchk.c:
Auto merged
myisam/sort.c:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
we change THD::system_thread from a 'bool' to a bitmap to be able to
distinguish between delayed-insert threads and slave threads.
- Fix for BUG#1701 "Update from multiple tables" (one line in sql_parse.cc,
plus a new test rpl_multi_update.test). That's just adding an initialization.
sql/repl_failsafe.cc:
comment to warn about this unused code
sql/slave.cc:
Now thd->system_thread is a bitmap, not a bool.
sql/sql_class.h:
'bool' for THD::system_thread is not accurate enough; sometimes we need
to distinguish between delayed-insert threads and slave threads;
so changing THD::system_thread to a bitmap (uint).
sql/sql_insert.cc:
thd.system_thread is now a bitmap
sql/sql_parse.cc:
We need to initialize thd->lex.select_lex.options in mysql_init_query();
it's already initialized in dispatch_command() but replication calls
mysql_parse() directly, thus bypassing dispatch_command().
Not initing it here leads to a query influencing the next query,
in the slave SQL thread.
The initialization in dispatch_command() must be kept as this
command uses the variable in tests, even when the command was not a
query (i.e. when mysql_init_query() was not called).