Bug #26591 Cluster handler does not set bits in null bytes correctly: Improved comments
ha_ndbcluster_binlog.cc:
Bug #26591 Cluster handler does not set bits in null bytes correctly: Using empty_record() instead of bzero
when there are no up-to-date system tables to support it:
- initialize the scheduler before reporting "Ready for connections".
This ensures that warnings, if any, are printed before "Ready for
connections", and this message is not mangled.
- do not abort the scheduler if there are no system tables
- check the tables once at start up, remember the status and disable
the scheduler if the tables are not up to date.
If one attempts to use the scheduler with bad tables,
issue an error message.
- clean up the behaviour of the module under LOCK TABLES and pre-locking
mode
- make sure implicit commit of Events DDL works as expected.
- add more tests
Collateral clean ups in the events code.
This patch fixes Bug#23631 Events: SHOW VARIABLES doesn't work
when mysql.event is damaged
When MySQL logged slow query information to a CSV table, it stored the
query_time and lock_time values with an incorrect formula.
If the time was over 59 seconds, this caused incorrect statistics (either the
slow query was not logged, or the time was far from correct). This change
fixes the method used to store those TIME values in the slow_log table.
In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced
subject table didn't see the results of operation which caused invocation
of those triggers. In other words AFTER trigger invoked as result of update
(or deletion) of particular row saw version of this row before update (or
deletion).
The problem occured because NDB handler in those cases postponed actual
update/delete operations to be able to perform them later as one batch.
This fix solves the problem by disabling this optimization for particular
operation if subject table has AFTER trigger for this operation defined.
To achieve this we introduce two new flags for handler::extra() method:
HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH.
These are called if there exists AFTER DELETE/UPDATE triggers during a
statement that potentially can generate calls to delete_row()/update_row().
This includes multi_delete/multi_update statements as well as insert statements
that do delete/update as part of an ON DUPLICATE statement.
is a special case in "SHOW PROFILE FOR QUERY n". No one can get
the zero item (which is always the statement that turns on profiling),
because zero represents the final item, internally.
Now, order the queries starting at one.
B-g#27501: 5.0 significantly more sys ("kernel") time than 4.1 \
due to getrusage() calls
Even if profiling is turned off, the parser makes calls to reset
the state at the beginning of each query. That would eventually
instantiate a PROFILE_ENTRY, which does indeed capture resource
usage.
Instead, now check that profiling is active before progressing
far into the storage/expiration of old entries in the history.
This has the pleasant side-effect that queries to toggle profiling
are not recorded in the history.
B-g#26600: table PROFILING in INFORMATION SCHEMA has wrong data type
B-g#27047[partial]: INFORMATION_SCHEMA table cannot have BIGINT \
fields
No Information_schema table has ever needed floating-point data
before. Transforming all floating point to a string and back to a
number causes a real data problem on Windows, where the libc may
pad the exponent with more leading zeroes than we expect and the
significant digits are truncated away.
This also makes interpreting an unimplemented type as a string into
a fatal error in debug builds. Thus, we will catch problems when we
try to use those types in new I_S tables.
B-g#27060: SQL Profile utility may not be reporting right duration \
for each step
Whenever the profiler is reset at the beginning of a query, there's
a "hidden" profiling entry that represents that point in time. It
has no status description, as those are set by state changes and no
such point has yet been encountered. That profiling entry is not
in the list of entries generated when we change states.
The profiling code had the problem that each step of printing
profiling data subtracted the previous "step"'s data, but gave the
label to that data of the current step, which is wrong. The label/
state refers to the period beginning with that profiling data, not
ending with it.
Now, give a label to the first profiling pseudo-entry, so that we
have a name to assign to the period that ends with the first state
change. Now also use the state name of the previous step in showing
the delta values that end with this step.
