[MDEV-11432] Change the informational redo log format tag to say "MariaDB 10.2.3" Created: 2016-11-30  Updated: 2017-03-17  Due: 2016-12-01  Resolved: 2016-12-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Fix Version/s: 10.2.3

Type: Task Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: innodb, xtrabackup

Issue Links:
Relates
relates to MDEV-11782 Redefine the innodb_encrypt_log format Closed
relates to MDEV-12103 Reduce the time of looking for MLOG_C... Closed
relates to MDEV-12288 Reset DB_TRX_ID when the history is r... Closed
relates to MDEV-11202 InnoDB 10.1 -> 10.2 migration does no... Closed

 Description   

MariaDB 10.2 incorporates MySQL 5.7. MySQL 5.7.9 introduced an informational field to the InnoDB redo log header, which identifies the creating server version, in
WL#8845: InnoDB: Redo log format version identifier
The informational message would be displayed to the user, for example if someone tries to start up MySQL 8.0 after killing a MariaDB 10.2 server.
In the current MariaDB 10.2 source code, the identifier string would misleadingly say "MySQL". We should change it to "MariaDB". We should also make sure that the correct version number is being written.
This would probably involve changing a single line in the file log0log.h:

#define LOG_HEADER_CREATOR_CURRENT	"MySQL " INNODB_VERSION_STR

This is only a cosmetic change. The compatibility check is based on a numeric identifier. We do not need to change that identifier as long as we are not changing the way how redo log records are being interpreted in crash recovery. So, MariaDB 10.2.3 and later would use a redo log format that is compatible with MySQL 5.7.x with x>=9.



 Comments   
Comment by Marko Mäkelä [ 2016-12-01 ]

I committed a patch that simply changes the string (it was "MySQL 5.7.14") to "MariaDB " followed by the version number from the VERSION file.

Comment by Jan Lindström (Inactive) [ 2016-12-01 ]

Ok to push.

Generated at Thu Feb 08 07:49:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.