I intentionally removed the MySQL implementation of the table in MDEV-11785, because it indeed is very limited (for example, does not show the table name).
MariaDB could implement something better, hopefully not limited to InnoDB.

marko: I Agree with you , the current Implementation is very limited, for example there is no way you can get the metadata info of a temporary table, for example to get the field list, because sometimes we need to generate a temporary table based on a prepared statement, and use that table to do some advanced operations. But we need to parse the field list because, as being a prepared statement the is no way we can know in advance the fields that the table will have.

Standard INFORMATION_SCHEMA.TABLES should show temporary tables too. The fourth column, TABLE_TYPE should be "LOCAL TEMPORARY". Standard also has "GLOBAL TEMPORARY" tables, but we don't support them yet.

serg, I would like to work on this issue, is that alright?

anel or cvicentiu can you please clarify the fixVersion?

Hi julien.fritsch I have updated fix-version, currently there is a PR for `10.3`.

cvicentiu, when do you think you can review this issue, please?

Also, aditionaly that they can shown in INFORMATION_SCHEMA.TABLES as 'LOCAL TEMPORARY'. MariaDB should be also able to show their fields in INFORMATION_SCHEMA.COLUMNS, and any other metadata associated to a normal table. But at least, implementing INFORMATION_SCHEMA.TABLES and INFORMATION_SCHEMA.COLUMNS will help a lot.

One usage for this feature is to be able to generate a JSON object from a Temporary Table/query (i.e CREATE TEMPORARY TABLE from a SELECT), for that, we need to know the field type to generate the correct JSON representation (i.e. Date values, Blob value, etc).

I looking for informations to analyse a trouble DDOS issue with replication.

any update ?

anel, I don't think there should be a special I_S table for that. Temporary tables should just show up normally in I_S.TABLES, I_S.COLUMNS, etc.

The following should be kept in mind:

• If the user does not have, say, PROCESS privilege, she can only see temp tables in the current connection.
• Perhaps there should be a new column for the connection id?
• Table type would be "TEMPORARY". Standard prescribes "GLOBAL TEMPORARY" or "LOCAL TEMPORARY" but our tables are neither, so let's just use "TEMPORARY".
• Column "TEMPORARY" should go, it serves no purpose
• if there's a new column for connection_id and the user queries WHERE CONN_ID=CONNECTIONID() the server should not iterate all threads.

another, much simpler approach, would be to show only temp tables for the current connection. Then connection_id column isn't needed.

perhaps, let's split the task. this one will only show temporary tables for the current connection and MDEV-15623 will be for showing temporary tables for all connections?

How will it work with "I_S.COLUMNS, etc."?
If one has a base table db.t1 (a int) and a temporary table db.t1 (b int), how will it be possible to determine which columns in I_S.COLUMNS belong to which table (etc.)?

Hi serg, elenst
ok, understood, single connection with privilege, no conn_id field in table structure and drop TEMPORARY field, assign type to I_S.TABLES field TABLE_TYPE.
Regarding the I_S.COLUMNS with the same names of base and temp tables, probably to extend EXTRA field or add another IS_TEMPORARY or TABLE_TYPE (but could be redundant to I_S.TABLES.TABLE_TYPE definition).
What else belongs to ,.etc ?
Note:
Currently KB is.tables missing TEMPORARY column, probably because [ todo modification after change]:

The Information Schema table shows information about the various non-TEMPORARY tables and views on the server.

Regarding the I_S.COLUMNS with the same names of base and temp tables, probably to extend EXTRA field or add another IS_TEMPORARY or TABLE_TYPE (but could be redundant to I_S.TABLES.TABLE_TYPE definition).
What else belongs to ,.etc ?

anel,
The "etc." part is important here. There is a number of tables in information_schema providing some extra information about tables, where the combination of table_schema and table_name is currently meant to identify a table unambiguously; the extra column would have to be added to all of them, it's a big redundancy. And then, if it's later decided to go for all connections, even that won't be sufficient because there can be be multiple temporary db.t1, different for each connection, so you'll also have to add a connection ID column to each of these other I_S tables.

elenst, good point. One possible solution: I_S tables show information on user visible tables, like, if you can do SELECT * FROM t1 then I_S tables will show information about t1. That is, if temporary table shadows the non-temporary table, then I_S tables only show the temporary table.

serg,

I'm not sure the users will appreciate it. I can think of two reasons right away, although there can be many more.

1) Currently if you happen to have a temporary table which is a namesake of a base table (as unwise as it may be), the only straightforward way to find out the structure of the base table is via the I_S tables. If you run SHOW CREATE TABLE, it will show you the temporary table, but you can get around it via the information_schema. With such a change, it will become much harder, if possible at all.

2) The inconsistency of I_S data can go very ugly very fast. Say, you have a relation (e.g. a foreign key) between two base tables, t2 references t1, and t1 has a temporary namesake. What should happen then when you're looking at a cross-reference I_S table, e.g. I_S.KEY_COLUMN_USAGE, for the table t2? You can't hide the entry for t2 because it is a normal unique base table, but it will show a reference to a column in the base table t1, and then if you try to find the column in other I_S tables, it might not be there because the temporary one doesn't have it (or even worse, it is there, but with a different column definition).

1) One can argue that it's a bug. That SHOW CREATE TABLE and I_S.TABLES shows different information.

2) Right. I don't have a good solution for that. But the same logic as above applies. One can do SHOW CREATE TABLE for t2, see that it references t1, then one does SHOW CREATE TABLE t1 and the column is not there.

Inconsistency is still there. And it not solved by the fact that this inconsistency is inconsistently present in only some commands, but not others.

1) One can only argue that SHOW CREATE TABLE is wrong. The fact that I_S.TABLES returns information about all non-temporary tables is documented, both in MariaDB KB and MySQL manual. On the other hand, the fact that SHOW CREATE TABLE returns information about a temporary table, while well-known, is not documented, neither in MariaDB KB nor (oddly) in MySQL manual.

2) Once again, it looks like we are going to attempt to solve inconsistency at the expense of common sense and usability – that is, to make things worse than they were from most practical points of view; and we don't even really get rid of inconsistency this time, we just replace one with another. Now I_S tables are consistent among themselves, but inconsistent with SHOW CREATE TABLE. This change will make certain I_S tables be consistent with SHOW CREATE TABLE, but instead they'll become inconsistent among themselves and still some I_S tables will be inconsistent with SHOW CREATE TABLE.

I don't think people query the information schema and/or run SHOW statements just to enjoy how perfectly they match, and neither do I believe that even users who now want to see temporary tables in the I_S will be happy when they realize that they have lost base tables as the result.

Both I_S and SHOW are run to gather certain information. If one method provides this information, in practice nobody will use another one and thus won't suffer from the inconsistency among them (except for maybe tester-like minds). If one method doesn't provide the required information, then the other one would be tried, and users will surely appreciate if it helps.

it's not even a question of consistency between SHOW CREATE and I_S.TABLES, it's that one cannot get the information on selectable tables from I_S. One can query I_S.TABLES see some columns for test.t1, then query this table to see completely different table structure.

I think it's better when I_S.TABLES shows the actual table that users see and can select from.

It is better if users can see both.
When users can only see one at the expense of another, it is not better, it is different, beneficial for some while disadvantageous for others.
And in our case "some" will get a new feature (even though in a form that they didn't request), while "others" will get an unexpected regression which they never asked for and which will contradict the currently documented behavior.

/me is still unclear design which should be used per redundancy which will occur.

For I_S.TABLES we can easily show both. They'll have different values in TABLE_TYPE, there can be no ambiguity.

What to do with I_S.COLUMNS, I_S.STATISTICS, I_S.TABLE_CONSTRAINTS, I_S.KEY_COLUMN_USAGE, I_S.PARTITIONS, I_S.FILES (?), I_S.CHECK_CONSTRAINTS. They all use TABLE_SCHEMA+TABLE_NAME to identify a table.

One backward compatible but a really inconsistent approach would be for normal tables to shadow temporary tables in I_S (except in I_S.TABLES that can show both).

This way everything will work intuitively correct unless one create a temporary table with the same name as a normal table.
And if one does it both SELECT and I_S tables will work in a backward-compatible manner, doing what they did before, that is exactly the opposite of what the other does.

Long term we should probably outlaw this shadowing behavior altogether.

So to proceed with and implement to I_S.TABLES only in this phase ?

okay, let's start from I_S.TABLES. But it won't solve MDEV-23643. We'll need to do something about I_S.COLUMNS too.

Note, that as I_S.TABLES doesn't show session id, it should only show temporary tables from the current session. Thus MDEV-15623 also says unresolved

So currently we have:

• column TABLE_TYPE for everything (BASE_TABLE, VIEW, etc) without TEMPORARY_TABLE,
• column TEMPORARY, set to N by default except for TABLE_TYPE= 'SYSTEM_VIEW' (I_S tables).
  Possible solution:
• Allow TABLE_TYPE to have TEMPORARY_TABLE and keep TEMPORARY column for SYSTEM_VIEW .
  In this case I think we should at least change the name of the column TEMPORARY, seems weird when reading that temporary table t1 has type TEMPORARY and that TEMPORARY column in the same entry is N).

Based on above, I have created one patch with some open questions in commit message and github comments, hope serg or someone else? will have time to review and point me further, thanks.

One more option:

• I_S.TABLES and all other related I_S tables only show temporary tables
  • for the current session
  • only if the name does not shadow any existing tables
• if the temporary table shadows the existing table, there's a Note at CREATE TABLE time, like "non-temporary table XXX already exists,the temporary table XXX won't be visible in I_S"
• there is a new I_S table (for MDEV-15623), for temp tables only, with columns like session_id, db_name, table_name, show_create_table, and whatever else is in I_S.TABLES

elenst, how about that? in normal use case (no shadowing) everything works normally. We sidestep and simply refuse to solve the case of shadowing. And there's a new table to see all temp tables in all sessions, but it generally cannot be joined with other I_S tables.

serg,

To me it sounds better (=~ more backward-compatible) than previous solutions, although please note that it won't be as straightforward as it sounds, right away there is a question of "isolation level", so to speak.

Say, connection 1 creates a temporary table myPoorTable.
It doesn't shadow any existing tables and thus no warning/notes are issued.
I_S queries in connection 1 (if it runs any) return information for this table.
Now, while connection 1 is still alive and has the table, connection 2 creates a non-temporary table myPoorTable.
What should I_S queries in connection 1 now return?

It's somewhat rhetorical as the only practical answer that I can imagine is "new non-temporary table", and I don't think it's necessarily a critical problem, but it may cause confusion and should be at least documented.

Also, I assume this solution still implies that the table type for temporary tables which are shown in the I_S (those which don't shadow anything) will be 'TEMPORARY', or there will be another column in I_S.TABLES indicating whether the table is temporary or not. It would make a lot of sense.

A "new non-temporary table", indeed. And yes, temporary tables in I_S.TABLES will be shown as "TEMPORARY"

I want to point out that this problem is critical. There aare some business problems, namely converting an arbitrary "Select" statement to an HTML table, con only be solved by reading the metada of a temporary table. If we cannot, then we need to use real tables, and concurrency becomes close to impossible.
Unless somebody can indicate a way to deliver a " select from (many tables joined)" query as an HTML table.

It would be unnecessary to change anything if we could do this
SET @sql = CONCAT('SHOW COLUMNS FROM ', schema_name, '.', table_name, ' WHERE @cs := TRIM("," FROM CONCAT(@cs, "''),(''", Field))');
EXECUTE IMMEDIATE @sql;

without returning an empty rowset, which is unnecessary for the logic.
The above technique works even with temporary tables, and it can be used in lieu of "select * from from information schema"
the problem is that we need to allow "do" before the "show columns", so the result set is discarded, and that is not possible now.
But maybe somebody knows how to fix this.

Specifically, how can I run this statement
set @cs='';SHOW COLUMNS FROM api.clients WHERE @cs := TRIM("," FROM CONCAT(@cs, "'),('", Field));
Query OK, 0 rows affected (0.00 sec)

Empty set (0.00 sec)
and not get an empty set?
Or to redirect the empty set to a temporary table that can be dropped, etc. Right now my app is discarding this unnecessary result. I am doing this only because there is no way to read the structure of a temporary table.
If somebody knows how to do this please respond.

philip_38, within the approach I've suggested in this comment, you'll be able to read the structure of a temporary table by selecting FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA='your_schema' AND TABLE_NAME='you_table'. It'll work both for normal and temporary tables.

That would be fantastic, but meanwhile, is there any obvious way that I have overlooked to avoid, cancel or redirect that extra empty result set?
Of course, it will be better to have your approach become a feature, but maybe is faster, just a few lines of code, to block that annoying extra empty set.

I have a question: Is there a way to retrieve metadata for a temporary table in version 5.6?
Any workaround?

Based on suggested design here is the patch bb1737b04828686 which allows temporary tables to be visible in information_schema.tables per thread. Howerver, there is the failure in buildbot for big-tests default_row_format_create - explained more in MDEV-26531

There is a missmatch between the Title and description of the task and what
is suggested to be implemented!

The task of changing information_schema.tables not part of the
MDEV-12459 description and should be moved to it's own MDEV that
clearly explain what should be done. (Or change the MDEV-12459
description to match the task)

Regarding 1)

Please describe the reason why we want to change the current
information_schema.tables content!

Yes, GLOBAL TEMPORARY and LOCAL TEMPORARY are standard, but as we have
neither, what is wrong with just continue using the current temporary
column?

In SQL SERVER, it looks like LOCAL TEMPORARY is almost exactly
matching our temporary tables (except that they are created with a '#'
leading sign. Please check what SQL SERVER uses in it's
information_schema tables and follow their lead.
Postgresql also uses LOCAL TEMPORARY.

In what way is our temporary tables so different from PostgreSQL and
SQL_SERVER?

2) and 3) are ok.

4) Don't do it.
We should NOT remove the 'Temporary' column as there may be users,
applications or tools that depends on this. Always remember that it is as
important to be backward compatible at is is to following the
standard. Best if we can do both.

References:
1) Don't understand the comment. There is nothing in the Jira entry
about connection_id.
2) Explain why our's are neither (comparing them to PostgreSQL and SQL Server)
I still think that they are closer to LOCAL than anything else.

3) Explain in the Jira what this is all about.
"But at least, implementing INFORMATION_SCHEMA.TABLES and
INFORMATION_SCHEMA.COLUMNS will help a lot."
We already have both. Please explain this more clearly.
4) Please add reasoning to the description and don't force people to read comments to understand what is going on.
Anyway, don't delete something you don't know who is using.

Is it a good idea to have a shared data structure of local temporary tables? It would seem to have some potential to be a performance bottleneck.

In InnoDB, I would love to remove the global hash table of temporary table names (MDEV-17805), but currently some handler::delete_table() calls are deleting temporary tables by name, not by an already opened handle. The names that are being used are not the user-specified connection-local table names, but some internally generated, globally unique names.

Based on MDEV-10356 and MDEV-25064, replication appears to assume that the supposedly local temporary tables are accessible from ‘foreign’ threads.

I think that we should thoroughly review what is really needed and wanted, before constraining ourselves by creating such a view.

Marko, there is no plans to have a shared data structure for Temporary tables. The idea is to loop over THD's and use the existing list of created temporary tables for this
There is no plans to list internal temporary tables or files used by the server (for now; We could use the structure in mysys to get the file names if we ever needed some information about used files...)

Regarding why we should not use LOCAL TEMPORARY, according to Serg the main issues seams to be that LOCAL TEMPORARY should survive the connection and can be shared among user.

To personally care more about interoperability for applications than following a standard that others may not follow either.
I did a quick check of how other SQL servers implement LOCAL TEMPORARY (seen from the Information schema point of view)

• MySQL puts TEMPORARY in Information schema and uses "termporary" as it's type. However the MySQL Java driver changes it to LOCAL TEMPORARY.
• SQL SERVER: A local temporary table is created using CREATE TABLE statement with the table name prefixed with single number sign (#table_name). In SQL Server, local temporary tables are visible only in the current session. So if you create a local temporary table in one session, you cannot access it in other sessions. Local temporary tables are deleted after the user disconnects from the instance of SQL Server.
• Oracle (version?) does not support Local Temporary table. It has only Global temporary table. Data is remain private at session level (1). Oracle 18C introduced "private temporary tables" that are session only. They are dropped at end of session (just like MariaDB's). Note that Oracle doesn't have information_schema.
  • PostrgreSQL: A temporary table, as its named implied, is a short-lived table that exists for the duration of a database session. PostgreSQL automatically drops the temporary tables at the end of a session or a transaction. It uses "LOCAL TEMPORARY" in information_schema.tables.

References:
(1) https://smarttechways.com/2019/08/27/global-and-local-temporary-table-in-oracle/

To add to the above, SQL Standard (2016) has no "TEMPORARY", there is no "CREATE TEMPORARY TABLE" at all. There is "CREATE GLOBAL TEMPORARY TABLE" and "CREATE LOCAL TEMPORARY TABLE", where the GLOBAL/LOCAL keyword is not optional. There's also "DECLARE LOCAL TEMPORARY TABLE" that we don't support. All standard global/local temporary tables do not disappear when a session ends. The difference between GLOBAL and LOCAL is minor and in my personal opinion not practically useful, I'd prefer the standard to have tables that are local to a session, but here we are.

MariaDB and MySQL have "CREATE TEMPORARY TABLE", so it make sense for MariaDB to call those tables "TEMPORARY", like MySQL does — the table type is what's between "CREATE" and "TABLE".

We can call them "PRIVATE TEMPORARY", kind of like Oracle, but Oracle doesn't use this wording in INFORMATION_SCHEMA.TABLES as far as I understand. So it'd be compatible with nothing.

Or we can do like PostgreSQL does and incorrectly call those tables "LOCAL TEMPORARY", which will go both against the standard and against our own "CREATE TEMPORARY TABLE" syntax.

Considering all the above, I believe we should use "TEMPORARY". This matches our existing syntax, is compatible with MySQL behavior, and does not violate standard definitions. If (when? one can hope) the standard introduces session-local temporary tables with a special name and syntax for them, then we can reconsider.

Note: In MS SQL Server, there are also global temporary tables, prefixed with ##, and they survive a connection closure. They are created in TEMPDB, a special system database.
We should do the same.

philip_38 its a new issue, please create a new task. How are they temporary if they survive a connection? (question for the new task)

I was just adding to Michael Widenius' statement on how other databases work. Furthermore, there are a lot of business cases for a temporary table that all users and processes can write to and read from, is located in TEMPDB andis specially cached. It gets truncated on reboot. So the idea is not bad.

Conceptually, how do global temporary tables differ from ENGINE=MEMORY tables? As far as I understand, those tables have persistent metadata, but the data will not survive a restart of the database server.

For those tables, the data is connection-local, while the metadata is global.

In SQL Server, global temporary tables are visible to all sessions (connections). So if you create a global temporary table in one session, you can start using it in other sessions.
A Global temporary table is automatically dropped when the session that created the table ends and the last active Transact-SQL statement (not session) referencing this table in other sessions ends.
For permanent common tables but with transient data, not surviving a reboot, I always define the table in Model DB, which becomes (a copy) the new TEMPDB on each reboot. Maybe we can emulate this approach.

Given that there are still open bugs related to the feature implementation and 10.9 is past the deadline, I recommend postponing the feature till 10.10.

I don't think it's a critical loss for the potential users of 10.9 release line, since the implementation doesn't really address the demand which was mentioned in the original report and repeated several times in the comments: there is still no way to list temporary table columns by the means of SELECT, and/or retrieve a temporary table structure from INFORMATION_SCHEMA. The implementation only allows to see which temporary tables exist in the session, and get some basic information about them (e.g. the engine and such).

As Elena Stepanova said, wisely, an implementation that would not allow seeing the columns, is useless. I vote to delay it until it works.

I think different tables should be used in I_S for temporary tables, as far as I know, there is no way to know globally how many temporary tables there are, which session created them and how much space they use (on disk or memory for engine=memory). This makes it very difficult to debug memory usage in environments with heavy use of temporary tables with engine=memory.

Also, actually a single connection can fill the entire memory of the server since temporary tables can be limited in space but not in number per session.

Please correct me if I'm wrong...

As agreed with Serg, moving this to 11.2 with the final specification:

This task will cover only the following behaviour for I_S.tables:

create table t1 (a int);

create sequence s1;

create temporary table t1 (b int);

create temporary sequence s1;

select table_schema, table_name, table_type, temporary

from information_schema.tables

where table_schema = 'test';

table_schema	table_name	table_type	temporary

test	s1	TEMPORARY SEQUENCE	Y

test	t1	TEMPORARY	Y

test	t1	BASE TABLE	N

test	s1	SEQUENCE	N

The added test main.information_schema_temp_table is massively failing. I spotted a failure of a MemorySanitizer build:

CURRENT_TEST: main.information_schema_temp_table

mysqltest: At line 220: query 'SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'test'' failed: <Unknown> (2013): Lost connection to server during query

…

==275990==WARNING: MemorySanitizer: use-of-uninitialized-value

    #0 0x55a317232d06 in ha_myisammrg::info(unsigned int) /home/buildbot/amd64-debian-11-msan/build/storage/myisammrg/ha_myisammrg.cc:1289:7

    #1 0x55a3147e651f in get_schema_tables_record(THD*, TABLE_LIST*, TABLE*, bool, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_show.cc:5793:11

    #2 0x55a3147da58a in process_i_s_table_temporary_tables(THD*, TABLE*, TABLE*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_show.cc:5930:3

    #3 0x55a3147da58a in get_all_tables(THD*, TABLE_LIST*, Item*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_show.cc:5347:9

    #4 0x55a31480bfdc in get_schema_tables_result(JOIN*, enum_schema_table_state) /home/buildbot/amd64-debian-11-msan/build/sql/sql_show.cc:9146:11

    #5 0x55a31469faec in JOIN::exec_inner() /home/buildbot/amd64-debian-11-msan/build/sql/sql_select.cc:4890:7

    #6 0x55a31469d411 in JOIN::exec() /home/buildbot/amd64-debian-11-msan/build/sql/sql_select.cc:4710:8

    #7 0x55a314610da7 in mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_select.cc:5239:21

    #8 0x55a31460f94d in handle_select(THD*, LEX*, select_result*, unsigned long long) /home/buildbot/amd64-debian-11-msan/build/sql/sql_select.cc:627:10

    #9 0x55a3144fa8cf in execute_sqlcom_select(THD*, TABLE_LIST*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_parse.cc:6030:12

    #10 0x55a3144de850 in mysql_execute_command(THD*, bool) /home/buildbot/amd64-debian-11-msan/build/sql/sql_parse.cc:3944:12

    #11 0x55a3144c76e9 in mysql_parse(THD*, char*, unsigned int, Parser_state*) /home/buildbot/amd64-debian-11-msan/build/sql/sql_parse.cc:7774:18

    #12 0x55a3144bde30 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /home/buildbot/amd64-debian-11-msan/build/sql/sql_parse.cc:1892:7

    #13 0x55a3144c8e12 in do_command(THD*, bool) /home/buildbot/amd64-debian-11-msan/build/sql/sql_parse.cc:1405:17

    #14 0x55a314b18736 in do_handle_one_connection(CONNECT*, bool) /home/buildbot/amd64-debian-11-msan/build/sql/sql_connect.cc:1416:11

    #15 0x55a314b17d39 in handle_one_connection /home/buildbot/amd64-debian-11-msan/build/sql/sql_connect.cc:1318:5

    #16 0x55a315de6dae in pfs_spawn_thread /home/buildbot/amd64-debian-11-msan/build/storage/perfschema/pfs.cc:2201:3

    #17 0x7f3293f35ea6 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7ea6) (BuildId: 255e355c207aba91a59ae1f808e3b4da443abf0c)

    #18 0x7f329393da2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfba2e) (BuildId: e15ec78d51a522023f9cfc58dc284f379d81860b)

  Uninitialized value was created by an allocation of 'mrg_info' in the stack frame of function '_ZN12ha_myisammrg4infoEj'

    #0 0x55a3172324d0 in ha_myisammrg::info(unsigned int) /home/buildbot/amd64-debian-11-msan/build/storage/myisammrg/ha_myisammrg.cc:1274

As far as I understand, myrg_status() will not initialize the errkey field if flag=HA_STATUS_POS.

I think that this must be fixed before the feature can be merged to any main branch.

Tested on preview-11.2-preview a238b9a87616794a24a9. OK to push into 11.2