When a CSV file contained comma separated elements
that were not enclosed in quotes, it was causing the
mysql server to crash.
The old algorithm that parsed the content of a row in
mysql 5.0 was assuming that the values of the fields
in a .CSV file will be enclosed in quotes and will be
separated by commas.
This was causing the old algorithm to fail when the
content of the file resembled the following
3,"sans quotes"
The CSV engine that is part of mysql 5.0 was expecting
the above to be
"3","sans quotes"
The above is just one example of where the engine was
failing for what would be recognized as a valid .CSV
file content otherwise.
The proposed fix changes the old algorithm being used
to parse rows from the .CSV file to handle two separate
cases
1) When the current field of the row is enclosed in quotes
2) When the current field of the row is not enclosed in
quotes
Re-enabling this test in 5.1 tree since the bug that caused disabling
(Bug#33696 CSV storage engine allows nullable colums via ALTER TABLE statements)
doesn't appear in 5.1 (6.0 only)
Recorded .result file and removed test from the main.disabled.def file.
GLOBAL STATUS is calculated by studying the list of threads. In the
embedded server threads were not linked to the internal list, so the
calculation always returns 0. Fixed by 'linking' the embedded-server
threads to the same list
per-file comments:
libmysqld/lib_sql.cc
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
Add newly created 'threads' to the internal thread list.
Remove them from the list as they're freed.
mysql-test/r/information_schema.result
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
test result
mysql-test/t/information_schema.test
Bug#34517 SHOW GLOBAL STATUS does not work properly in embedded server.
test case added
Item_func_div didn't calculate the precision of the result properly.
The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
to the planned precision.
per-file comments:
mysql-test/r/type_newdecimal.result
Bug#31616 div_precision_increment description looks wrong
test result fixed
mysql-test/t/type_newdecimal.test
Bug#31616 div_precision_increment description looks wrong
test case
sql/item_func.cc
Bug#31616 div_precision_increment description looks wrong
precision must be increased with args[1]->decimals parameter
tables can cause server to crash!
The bug will be fixed by patch for #34779: "crash in checksum table
on federated tables with blobs containing nulls"
Only a test case commited.
when InnoDB frm file corruption
Problem: mysqlcheck runs 'SHOW FULL TABLE' queries to get table lists.
The query may fail for some reasons (e.g. null .frm file) then
mysqlcheck doesn't process the database tables.
Fix: try to run 'SHOW TABLES' if 'SHOW FULL TABLES' failed.
VARIABLE_VALUE field is decreased to 1024 symbols.
(affected I_S tables: GLOBAL_VARIABLES, SESSION_VARIABLES,
GLOBAL_STATUS, SESSION_STATUS).
The only variable which can be longer than 1024 is
init_connect. The variable will be truncated with warning.
Additional fix:
Added where condition filter which speed up queries which
have where condition with expressions which use VARIABLE_NAME
field.
changed 'charset', 'collation' field length from 64 to MY_CS_NAME_SIZE(32)
in tables:
SCHEMATA, TABLES, COLUMNS, CHARACTER_SETS,
COLLATIONS, COLLATION_CHARACTER_SET_APPLICABILITY
With fix for bug 25951 index hints are ignored for fulltext
searches, as handling of fulltext indexes is different from
handling regular indexes. Meaning it is not possible to
implement true index hints support for fulltext indexes within
the scope of current fulltext architecture.
The problem is that prior to fix for bug 25951, some useful
index hints still could be given for boolean mode searches.
This patch implements special index hints support for fulltext
indexes with the following characteristics:
- all index hints are still ignored for NLQ mode searches -
it cannot work without an index;
- for 5.1 and up index hints FOR ORDER BY and FOR GROUP BY are
still ignored for fulltext indexes;
- boolean mode searches honor USE/FORCE/IGNORE INDEX hints;
- as opposed to index hints for regular indexes, index hints
for fulltext BOOLEAN mode searches affect the usage of the
index for the whole query.
on tables with partitions
Problem was that the handler function try_semi_consistent_read
was not propagated to the innodb handler.
Solution was to implement that function in the partitioning
handler.
The convert_constant_item function converts a constant to integer using
field for condition like 'field = a_constant'. In some cases the
convert_constant_item is called for a subquery when outer select is already
being executed, so convert_constant_item saves field's value to prevent its
corruption. For EXPLAIN and at the prepare phase field's value isn't
initialized yet, thus when convert_constant_item tries to restore saved
value it fails assertion.
Now the convert_constant_item doesn't save/restore field's value if it's
haven't been read yet. Outer constant values are always saved.
order by
Problem was that the first index read was unordered,
and the next was ordered, resulting in use of
uninitialized data.
Solution was to use the correct variable to see if
the 'next' call should be ordered or not.
Bug#39848 events_bugs fails sporadically on pushbuild
(missing rows in table event_log)
Details: Reimplement the subtest for BUG 28924
- check if the number of rows within the table
event_log changes but don't print rows
because the number varies depending on
load on testing box
- shift DROP USER befor DROP EVENT
= Subtest fits again to old bug
- remove no more needed comments + variables
Bug#39863 events_bugs fails sporadically on pushbuild
(extra processes in I_S.PROCESSLIST)
Details: Abort with appropriate message to the protocol if
release_lock() does not has the intended effect.
This cannot prevent problems caused by the probably
buggy release_lock() but it reveals if we had a
problem in this area.
Bug#39978 main.events_bugs does not clean up
Detail: Restore global.event_scheduler = ON at end of test
Bug#39569 events_bugs fails sporadically on pushbuild
(should have failed with errno 1539)
Detail: Set $wait_timeout to 4 instead of 2
- Fix two instabilities (result sets pulled from processlist in
subtest for bug 16407) which were found during tests with high
parallel I/O load
- Minor improvements of formatting
Details:
- Add comments
- Remove tabs and trailing blanks
- Add line breaks for better readability
The partitioning clause is only a very long single line, which is very
hard to interpret for a human. This patch breaks the partitioning
syntax into one line for the partitioning type, and one line per
partition/subpartition.
When statement-based replication is used, and the
transaction isolation level is READ-COMMITTED or stricter,
InnoDB will print an error because statement-based
replication might lead to inconsistency between master
and slave databases. However, when the binary log is not
engaged, this is not an issue and an error should
not be printed.
This patch makes thd_binlog_format() return BINLOG_FORMAT_
UNSPEC when the binary log is not engaged for the given
thread.
Problem was that partitioning cached the table flags.
These flags could change due to TRANSACTION LEVEL changes.
Solution was to remove the cache and always return the table flags
from the first partition (if the handler was initialized).
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
The convert_constant_item function converts a constant to integer using
field for condition like 'field = a_constant'. When the convert_constant_item
is called for a subquery the outer select is already being executed, so
convert_constant_item saves field's value to prevent its corruption.
For EXPLAIN field's value isn't initialized thus when convert_constant_item
tries to restore saved value it fails assertion.
Now the convert_constant_item doesn't save/restore field's value
for EXPLAIN.
Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.
Fix: reinsert data altering an enum field if enum values are changed.
