MDEV-13542 would ultimately propagate the error to the SQL layer. Even before that, we definitely could improve the messages that are output to the error log.

I think that it would be better in these messages to display the file name. I would still keep the tablespace ID in the output.
Starting with 10.2, many such messages are emitted via

/** Print the given page_id_t object.

@param[in,out]	out	the output stream

@param[in]	page_id	the page_id_t object to be printed

@return the output stream */

std::ostream&

operator<<(

	std::ostream&		out,

	const page_id_t		page_id)

{

	out << "[page id: space=" << page_id.m_space

		<< ", page number=" << page_id.m_page_no << "]";

	return(out);

}

which produces more verbose output.

The message was originally introduced in MDEV-11759 (MariaDB 10.1.22, 10.2.5) and slightly changed in MDEV-11939 (MariaDB 10.1.26, 10.2.8). (The original wording was "Page %lu in space %s (%lu) maybe corrupted."

Ultimately, the message and the code path leading to it was removed in MDEV-12112 (MariaDB 10.1.38, 10.2.20, 10.3.12).

The presence of this message in an error log spells big trouble. The logic that was introduced in MDEV-11759 was based on the wrong assumption that a data page whose contents appears to carry a valid ‘before encryption’ checksum cannot have been encrypted. Then, MariaDB would wrongly skip the page decryption and hand over the garbled page contents to the caller of buf_page_get_gen(), which would then crash basically anywhere. If I remember correctly my debugging session from December 2018, in MariaDB Server 10.1, buf_page_get_gen() would return NULL in this case. Some of its callers are prepared for that error situation.

To make matters worse, there are several checksum algorithm implementations in InnoDB. It sufficed for one of the various algorithms to produce a matching checksum. MDEV-17957 and MDEV-17958 improved innodb_checksum_algorithm=strict_crc32 so that only one checksum will be attempted.

In the case of one customer, an encrypted page had the exact same CRC-32C checksum both for the before-encryption and after-encryption checksums.

MDEV-18025 extended the test mariabackup.encrypted_page_corruption to cover a scenario where an encrypted page appears to contain a valid checksum on the encrypted data. The test ensures that InnoDB will attempt page decryption of an intentionally corrupted encrypted page, and only then detect that the decrypted contents of the page does not match the before-encryption checksum.

Ah, OK. It's good to know that the code path was removed.

Thanks for the analysis!

It looks like innochecksum still prints a similar message about corruption in the "Page $space_id:$page_num" format that has confused some people if you'd want to change that one too:

https://github.com/MariaDB/server/blob/7d245083a43e34d94822e580037727bdbb50b6f0/extra/innochecksum.cc#L527

Thanks for the clarification. I am lowering the priority from Critical. I would keep the terse format in messages that are only present in instrumented debug builds, but I agree that a more verbose format could be easier for users.

Diagnostics from topic message was removed in https://github.com/mariadb/server/commit/8c43f963882a9d5ac4e4289c8dd3dbcaeb40a0ce