- Use 'poll' if available
- Check that sd <= FD_SETSIZE if using 'select'
- Handle case when 'net_data_is_ready' returns -1, ie. sd > FD_SETSIZE and 'select' is used
--skip-grant-tables. However when deleting functions UDFs list was checked
regardless of whther UDFs are initialized or not. Additional check is added
into free_udf() and find_udf() functions to prevent possible runtime errors.
- Added empty constructors and virtual destructors to many classes and structs
- Removed some usage of the offsetof() macro to instead use C++ class pointers
Let us transfer triggers associated with table when we rename it (but only if
we are not changing database to which table belongs, in the latter case we will
emit error).
To quote Timour review lines:
The actual cause of the bug is that sql_base.cc:setup_wild()
sets "select_lex->with_wild = 0" (in the end of the function) once
it expands all wild-cards, and wild-card expansion is done during
the prepare phase. During this phase we replace all "*" with the
corresponding items, which for views happen to be references to
references. When we do execute, select_lex->with_wild = 0, and
all "*" are already replaced by the corresponding items, which
in the case of views need to be dereferenced first.
Fixed by refining the assert. Regression test for the bug is rpl_row_view01,
as was reported.
The cause of the bug was an ASSERT that checked the consistency
of TABLE_SHARE::db and TABLE_LIST::db and failed for I_S tables.
The fix relaxes the requirement for consistency for I_S.
column is increasing when table is recreated with PS/SP":
make use of create_field::char_length more consistent in the code.
Reinit create_field::length from create_field::char_length
for every execution of a prepared statement (actually fixes the
bug).
When a too long field is used for a key, only a prefix part of the field is
used. Length is reduced to the max key length allowed for storage. But if the
field have a multibyte charset it is possible to break multibyte char
sequence. This leads to the failed assertion in the innodb code and
server crash when a record is inserted.
The make_prepare_table() now aligns truncated key length to the boundary of
multibyte char.
symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N
(where N is interpreted like if SQL_MODE was a field of type SET), so
this bug affected recovery from binlogs if the server was running with certain SQL_MODE values,
for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people
had to edit mysqlbinlog's output.
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log
contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded
(error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK
should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0,
so that there is no false alarm.
