Bug#112704: Fix TempTable CTE clone handler mismatch when TempTable falls back to InnoDB

[catalinbp]

Bug#112704: Fix TempTable CTE clone handler mismatch when TempTable falls back to InnoDB

When TempTable materialization hits RECORD_FILE_FULL and falls back to
InnoDB, the other TABLE objects of the same temporary table keep the
TempTable handlers they were assigned earlier, while the table itself is
created in InnoDB. Opening such an objects fails with "Table doesn't
exist". Non-recursive CTE refs hit this in create_materialized_table()'s
shortcut path, recursive refs in FollowTailIterator::Init().

Fix in create_tmp_table_with_fallback(): on fallback, renew the creating
TABLE's handler and record InnoDB in the shared TABLE_SHARE (db_plugin),
so TABLE_SHARE::db_type() names the engine the table actually lives in.
open_tmp_table() then detects a handler that does not match the share's
engine and renews it (via reset_tmp_table_handler()) before opening.

As a consequence of the share now being accurate, a table that falls
back to InnoDB at create time is counted in Created_tmp_disk_tables,
which fixes Bug#36845804, so main.temptable_status_vars is also
re-recorded accordingly.

[mysql-oca-bot]

Hi, thank you for submitting this pull request. In order to consider your code we need you to sign the Oracle Contribution Agreement (OCA). Please review the details and follow the instructions at https://oca.opensource.oracle.com/
Please make sure to include your MySQL bug system user (email) in the returned form.
Thanks

[catalinbp]

Hi, thank you for submitting this pull request. In order to consider your code we need you to sign the Oracle Contribution Agreement (OCA). Please review the details and follow the instructions at https://oca.opensource.oracle.com/ Please make sure to include your MySQL bug system user (email) in the returned form. Thanks

I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

[mysql-admin]

Hi @catalinbp
Unfortunately we can't match you with an OCA on file.
Please contact Lenka lenka.kasparova@oracle.com to resolve the issue

Thanks for contributing to MySQL
==Omer

[catalinbp]

Done. The OCA should be connected to the username now.

[mvcc]

Thank you for the contribution — the share->db_plugin update is the right fix. One suggestion: both clone-open sites do the same swap immediately before open_tmp_table(); putting the file->ht != share->db_type() check at the top of open_tmp_table() itself would cover both (and any future callers) in one place. Could you also rebase onto current trunk?

[catalinbp]

Hi @mvcc !
Thanks for the review comments, I've addressed them all. It seems like there are some issue on the infrastructure side as it cannot run some checks: "Refusing to check out fork pull request code from a 'pull_request_target' workflow. This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope, and runner access.". I suppose that can be done manually.

Thanks,
\Catalin

[mvcc]

Thanks — reset_tmp_table_handler() is exactly what I had in mind, and creating the new handler before destroying the old one is a nice improvement over the code it replaces. It cherry-picks cleanly onto current trunk and builds clean here. Two more result files need re-recording though: opt_hints_set_var and opt_hints_set_var_hypergraph both fail on Created_tmp_files going 1 -> 0 for the COUNT(DISTINCT) case with tmp_table_size=1024. That looks like a knock-on effect of share->db_type() now reporting InnoDB — Aggregator_distinct::setup() only builds a Unique when the engine is TempTable/MEMORY, so after the fallback it dedups through the InnoDB index and no longer spills to a temp file. COUNT(DISTINCT a) still returns 128, so Created_tmp_files 0 looks like the correct new expectation for those two files — just a re-record, no code change.

[catalinbp]

@mvcc done, I've also re-recorded mem_cnt_sql_keys triggered by the same issue as the one above (Unique)