Hi, Igor On Apr 14, IgorBabaev wrote:
revision-id: a91fdd1288b3cbc5616f2ef9e0ce04bf7f0ef9ce (mariadb-10.2.14-35-ga91fdd1) parent(s): 740fc2ae084f8f81990de557d696aefbc507752d author: Igor Babaev committer: Igor Babaev timestamp: 2018-04-14 21:32:41 -0700 message:
Fixed the bug mdev-15575 different results when using CTE and big_tables=1.
please, make the first line MDEV-15575 different results when using CTE and big_tables=1 most other developers use that pattern, so your commits really stand out in the history, e.g.: 4c7a1a1 MDEV-15780 : mariabackup does not handle absolute names in for system tablespaces 9124590 MDEV-12903: encryption.innodb_encryption_discard_import fails in buildbot with FOUND vs NOT FOUND dd12779 MDEV-15832 With innodb_fast_shutdown=3, skip the rollback of connected transactions 740fc2a Fixed mdev-15765 BETWEEN not working in certain cases 8334ace MDEV-14380 Reduce possibility to timing-induced error in test and the reason for that is that many tools show only first 50 characters of the commit summary (first line), so starting it with the "Fixed the bug " does not add new information, but only pushes the relevant content to the right to be truncated.
This bug happened due to a defect of the implementation of the handler function ha_delete_all_rows() for the ARIA engine. The function maria_delete_all_rows() truncated the table, but it didn't touch the write cache, so the cache's write offset was not reset. In the scenario like in the function st_select_lex_unit::exec_recursive when first all records were deleted from the table and then several new records were added some metadata became inconsistent with the state of the cache. As a result the table scan function could not read records at the end of the table. The same defect could be found in the implementation of ha_delete_all_rows() for the MYISAM engine mi_delete_all_rows().
This is ok to push
Additionally made late instantiation for the temporary table used to store rows that were used for each new iteration when executing a recursive CTE.
I didn't review this part. Regards, Sergei Chief Architect MariaDB and security@mariadb.org