only const tables
The problem was caused by two shortcuts in the optimizer that
are inapplicable in the ROLLUP case.
Normally in a case when only const tables are involved in a
query, DISTINCT clause can be safely optimized away since there
may be only one row produced by the join. Similarly, we don't
need to create a temporary table to resolve DISTINCT/GROUP
BY/ORDER BY. Both of these are inapplicable when the WITH
ROLLUP modifier is present.
Fixed by disabling the said optimizations for the WITH ROLLUP
case.
The SE API requires mysql to notify the storage engine that
it's going to read certain tables at the beginning of the
statement (by calling start_stmt(), store_lock() or
external_lock()).
These are typically called by the lock_tables().
However SHOW CREATE TABLE is not pre-locking the tables
because it's not expected to access the data at all.
But for some view definitions (that include comparing a
date/datetime/timestamp column to a string returning
scalar subquery) the JOIN::prepare may still access data
when materializing the scalar non-correlated subquery
in Arg_comparator::can_compare_as_dates().
Fixed by not materializing the subquery when the function
is called in a SHOW/EXPLAIN/CREATE VIEW
If --log-bin is set to a directory name with the trailing 'FN_LIBCHAR',
which will be '/' on Unix like systems, and '\\' on Windows like systems.
the basename of the binlog is empty so that the created files named
'.000001' and '.index'. It is not expected.
The same thing happened to --log-bin-index, --relay-log and
--relay-log-index options.
To resolve the problem, in these cases the program should report an error
and abort.
Bug#42662: maketime() and signedness
Item_time_typecast::val_int() dropped sign from
MYSQL_TIME gotten using from get_time().
Propagates sign now.
Backported to 5.5.0 (6.0-codebase revid: 1810.3897.1)
When less than six places are given for microseconds, we zerofill from
the right (leftmost place is always 1/10s). We only did this when all
announced date/time fields were given; now we also format fractional
seconds when more significant fields are left out.
Non-transactional updates that take place inside a transaction present problems
for logging because they are visible to other clients before the transaction
is committed, and they are not rolled back even if the transaction is rolled
back. It is not always possible to log correctly in statement format when both
transactional and non-transactional tables are used in the same transaction.
In the current patch, we ensure that such scenario is completely safe under the
ROW and MIXED modes.
Bug#41756 "Strange error messages about locks from InnoDB".
In JT_EQ_REF (join_read_key()) access method,
don't try to unlock rows in the handler, unless certain that
a) they were locked
b) they are not used.
Unlocking of rows is done by the logic of the nested join loop,
and is unaware of the possible caching that the access method may
have. This could lead to double unlocking, when a row
was unlocked first after reading into the cache, and then
when taken from cache, as well as to unlocking of rows which
were actually used (but taken from cache).
Delegate part of the unlocking logic to the access method,
and in JT_EQ_REF count how many times a record was actually
used in the join. Unlock it only if it's usage count is 0.
Implemented review comments.
Bug#41756 "Strange error messages about locks from InnoDB".
In JT_EQ_REF (join_read_key()) access method,
don't try to unlock rows in the handler, unless certain that
a) they were locked
b) they are not used.
Unlocking of rows is done by the logic of the nested join loop,
and is unaware of the possible caching that the access method may
have. This could lead to double unlocking, when a row
was unlocked first after reading into the cache, and then
when taken from cache, as well as to unlocking of rows which
were actually used (but taken from cache).
Delegate part of the unlocking logic to the access method,
and in JT_EQ_REF count how many times a record was actually
used in the join. Unlock it only if it's usage count is 0.
Implemented review comments.
For application compatibility reasons MySQL converts "<autoincrement_column> IS NULL"
predicates to "<autoincrement_column> = LAST_INSERT_ID()" in the first SELECT following an
INSERT regardless of whether they're top level predicates or not. This causes wrong and
obscure results when these predicates are combined with others on the same columns. Fixed
by only doing the transformation on a single top-level predicate if a special SQL mode is
turned on (sql_auto_is_null).
Also made sql_auto_is_null off by default.
per-file comments:
mysql-test/r/func_isnull.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
test result updated
mysql-test/t/func_isnull.test
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
test case added
sql/mysqld.cc
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
sql_auto_is_null now is OFF by default.
sql/sql_select.cc
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
remove_eq_conds() split in two parts - one only checks the upper condition,
the req_remove_eq_conds() recursively checks all the condition tree.
mysql-test/extra/rpl_tests/rpl_insert_id.test
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
test fixed (set the sql_auto_is_null variable)
mysql-test/r/mysqlbinlog.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/r/mysqlbinlog2.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/r/odbc.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/r/query_cache.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/r/user_var-binlog.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/suite/binlog/r/binlog_row_ctype_ucs.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/suite/rpl/r/rpl_insert_id.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/suite/rpl/r/rpl_row_mysqlbinlog.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/suite/rpl/r/rpl_sp.result
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
result updated
mysql-test/t/odbc.test
Bug#41371 Select returns 1 row with condition "col is not null and col is null"
test fixed (set the sql_auto_is_null variable)
values return too many records
WHERE clauses with "outer_value_list NOT IN subselect" were
handled incorrectly if the outer value list contained multiple
items where at least one of these could be NULL. The first
outer record with NULL value was handled correctly, but if a
second record with NULL value existed, the optimizer would
choose to reuse the result it got on the last execution of the
subselect. This is incorrect if the outer value list has
multiple items.
The fix is to make Item_in_optimizer::val_int (in
item_cmpfunc.cc) reuse the result of the latest execution
for NULL values only if all values in the outer_value_list
are NULL.
When a sessione is closed, all temporary tables of the session are automatically
dropped and are binlogged. But it will be binlogged with wrong database names when
the length of the temporary tables' database names are greater than the
length of the current database name or the current database is not set.
Query_log_event's db_len is forgot to set when Query_log_event's db is set.
This patch wrote code to set db_len immediately after db has set.
ONLY_FULL_GROUP_BY
Problem was that during checking and preparation of the
partitioining function as a side effect in fix_fields
the full_group_by_flag was changed.
Solution was to set it back to its original value after
calling fix_fields.
Updated patch, to also exclude allow_sum_func from being
affected of fix_fields, as requested by reviewer.
Bug#31621: Windows server hanging during shutdown using named pipes
and idle connection
Problem: when idle pipe connection is forcefully closed with KILL
statement or when the server goes down, thread that is closing connection
would hang infinitely in CloseHandle(). The reason for the hang is that
named pipe operations are performed synchronously. In this mode all IOs
on pipe are serialized, that is CloseHandle() will not abort ReadFile()
in another thread, but wait for ReadFile() to complete.
The fix implements asynchrnous mode for named pipes, where operation of file
are not synchronized. Read/Write operation would fire an async IO and wait for
either IO completion or timeout.
Note, that with this patch timeouts are properly handled for named pipes.
Post-review: Win32 timeout code has been fixed for named pipes and shared
memory. We do not store pointer to NET in vio structure, only the read and
write timeouts.
