Problem described in this bug report affects MyISAM tables only.
Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.
This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.
myisam/mi_update.c:
Every myisam function that updates myisam table must end with
call to _mi_writeinfo(). If operation (second param of
_mi_writeinfo()) is not 0 it sets share->changed to 1, that is
flags that data has changed. If operation is 0, this function
equals to no-op in this case.
mi_update() must always pass !0 value as operation, since even if
there is no index change there could be data change.
fixups after review by jonas
ndb/src/mgmclient/CommandInterpreter.cpp:
Guard the print mutex when running SHOW
ndb/src/mgmsrv/MgmtSrvr.cpp:
replace global_flag_send_heartbeat_now with forceHB()/updateStatus()
don't use bitmask as parameter to forceHB to reflect reality of what the
function does.
remove get_connected_ndb_nodes() as it is no longer used
ndb/src/mgmsrv/MgmtSrvr.hpp:
remove unused get_connected_ndb_nodes()
update updateStatus prototype
ndb/src/mgmsrv/Services.cpp:
use new prototype for updateStatus() - doesn't accept NodeBitmask
ndb/src/ndbapi/ClusterMgr.cpp:
remove global_flag_send_heartbeat_now, replace with forceHB.
compute bitmask of nodes to send HB to in forceHB
ndb/src/ndbapi/ClusterMgr.hpp:
update prototype for forceHB, don't give the illusion that NodeBitmask means much.
into sunlight.local:/local_work/leak_fix
sql/sql_base.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/table.cc:
Auto merged
sql/sql_view.cc:
Manually merged
issue an error in case of DECIMAL(M,N) if N > M
mysql-test/r/type_newdecimal.result:
Bug#16172 DECIMAL data type processed incorrectly
result fix & test case
mysql-test/t/type_newdecimal.test:
Bug#16172 DECIMAL data type processed incorrectly
test fix
we intentionally reported that for TIMESTAMPS, which isn't right
mysql-test/r/type_timestamp.result:
result fixed
mysql-test/t/type_timestamp.test:
testcase added
sql/sql_show.cc:
remove the check for TIMESTAMP type -
all types will report 'NO' if they're defined as NOT NULL
Make sure totSendlenAi is set in case of ACC_ABORTCONF and activeCreate == true
(only needed when >2 replica)
ndb/src/kernel/blocks/dblqh/DblqhMain.cpp:
Make sure totSendlenAi is set in case of ACC_ABORTCONF and activeCreate == true
into willster.(none):/home/stewart/Documents/MySQL/5.0/bug13985
ndb/src/mgmsrv/MgmtSrvr.cpp:
Auto merged
ndb/src/mgmsrv/MgmtSrvr.hpp:
Auto merged
ndb/src/mgmsrv/Services.cpp:
Auto merged
ndb/src/mgmclient/CommandInterpreter.cpp:
manually merge parameter to pass print mutex to event thread
str_to_date() would sometimes render NULL if %D was used as rule other than last.
since this was due to two pointers getting mixed up in the server, this behaviour
seemed somewhat non-deterministic at SQL level.
mysql-test/r/func_time.result:
Bug #20987: str_to_date doesn't accept user variable for specification
show we can do the usual str_to_date() conversions without triggering the bug.
mysql-test/t/func_time.test:
Bug #20987: str_to_date doesn't accept user variable for specification
show we can do the usual str_to_date() conversions without triggering the bug.
sql/item_timefunc.cc:
Bug #20987: str_to_date doesn't accept user variable for specification
str_to_date() used a wrong pointer in %D conversions which could lead to the
input being cut off after the token matching %D; if the rule required further
tokens, the conversion would fail and render NULL.
set properly. This patch should fix that.
mysqld.cc:
Call test_if_case_insensitive in all cases so lower_case_file_system always gets set
sql/mysqld.cc:
Call test_if_case_insensitive in all cases so lower_case_file_system always gets set
