The HintParser wrongly ignored linebreaks, causing parsing faults
e.g. parsing too far or accepting invalid comments. Now, the parser
detects a line break and terminates comments unless they started with
'/*'. Also, fixed a memory leak when parsing parameter-value-combinations.
Whenever a server which is a slave of an external master is detected, it
will be assigned the slave status. This will allow the status to be used
the way it was intended to be used.
The modutil_get_SQL()-function allocates storage, while
modutil_extract_SQL() does not. The strings given by the latter
are not 0-terminated so require a length limit when matched using
regexec().
This commit changes the used function in those cases where the
sql-string is not modified nor is the pointer saved for later use.
The addition of field types and lengths wasn't added to the avrorouter
ALTER TABLE handler. This caused crashes when an alter table was done and
new rows were inserted afterwards.
The `monitoruser` and `monitorpw` parameters were mislabeled as `monuser`
and `monpw`. To allow backwards compatibility, the `monuser` and `monpw`
still work as aliases for the correct commands.
The type and name parsing functions could move outside of allocated memory
as they didn't check for the terminating null character. Also fixed the
printf format string used when the list of used tables is being created.
Fixed CDC testing connector to abort on error and added some extra output
to the cdc_datatypes test.
The type and name parsing functions could move outside of allocated memory
as they didn't check for the terminating null character. Also fixed the
printf format string used when the list of used tables is being created.
Fixed CDC testing connector to abort on error and added some extra output
to the cdc_datatypes test.
The schema generator program needs to add the real_type and length fields
if the data types define them.
Also fixed a bug where the real_type and length fields were checked for
generated fields.
The DATETIME(n) values generated by a MariaDB 10.0 server were not
interpreted correctly as the wrong algorithm was used to extract the
values.
DATETIME(0) values still do not work properly and they require further
debugging and changes to the code.
The avro schema allows custom properties to be defined for the schema
fields. The avrorouter stored extra information about the table into the
schema for later use.
Currently, this information is only generated by the avrorouter
itself. Further improvements to the schema generator scripts need to be
done.
When the binlog has been read, it needs to be treated as if the
transaction or row limit has been hit. This will cause all tables to be
flushed to disk before the files are indexed.
When a MariaDB 10.0 DATETIME field with a custom length was defined, the
field offsets weren't calculated properly.
As there is no metadata for pre-10.1 DATETIME types with decimal
precision, the metadata (i.e. decimal count) needs to be gathered from the
CREATE TABLE statement. This information is then used to calculate the
correct field length when the value is decoded.
This change does not fix the incorrect interpretation of the old DATETIME
value. The converted values are still garbled due to the fact that the
value needs to be shifted out of the decimal format before it can be
properly converted.
The DATETIME(n) values generated by a MariaDB 10.0 server were not
interpreted correctly as the wrong algorithm was used to extract the
values.
DATETIME(0) values still do not work properly and they require further
debugging and changes to the code.
The avro schema allows custom properties to be defined for the schema
fields. The avrorouter stored extra information about the table into the
schema for later use.
Currently, this information is only generated by the avrorouter
itself. Further improvements to the schema generator scripts need to be
done.
When the binlog has been read, it needs to be treated as if the
transaction or row limit has been hit. This will cause all tables to be
flushed to disk before the files are indexed.
When a MariaDB 10.0 DATETIME field with a custom length was defined, the
field offsets weren't calculated properly.
As there is no metadata for pre-10.1 DATETIME types with decimal
precision, the metadata (i.e. decimal count) needs to be gathered from the
CREATE TABLE statement. This information is then used to calculate the
correct field length when the value is decoded.
This change does not fix the incorrect interpretation of the old DATETIME
value. The converted values are still garbled due to the fact that the
value needs to be shifted out of the decimal format before it can be
properly converted.
When the connection timeout was checked for a connection, it assumed that
only valid and fully established sessions should be timed out.
Taking into account the fact that connections can be idle even before the
session is fully established, the check should be expanded to all
connections regardless of the session state.
The fixed length string processing assumed that the string lengths were
contained in the first byte. This is not true for large fixed length
strings that take more than 255 bytes to store. This consists of
multi-byte character strings that can take up to 1024 bytes to store.
If a complete response is delivered in many buffers, then calling
gwbuf_length() whenever you need the complete size starts to hurt.
By caching the length of the data received sofar and by updating
the length in clientReply(), gwbuf_length() will be called exactly
once for each buffer(chain) delivered to routeQuery().
