mariadb/sql/share
Nikita Malyavin e2e79ad916 MDEV-35915 Implement Global temporary tables
Global temporary table (GTT) is a table with globally defined metadata,
but per-session data.

That is, the life duration of this data is limited with session
duration. Here we have two options:

1. ON COMMIT DELETE ROWS: a default option. The life duration of data is
transaction duration.
2. ON COMMIT PRESERVE ROWS: The life duration of data is session
duration.

# Implementation

The implementation consists of the following fundamental parts.

## Part 1: CREATE TABLE + frm format

1. Store GLOBAL TEMPORARY and ON COMMIT bits in
   create_info->table_options
2. Store higher word of create_info->table_options in frm header
3. Also disallow ON COMMIT keyword for (local) temporary tables

As a result, the bits will be available in share->db_create_options.

New Table_type enum element: TABLE_TYPE_GLOBAL_TEMPORARY (datadict.h)

## Part 2: open_table: a local data table is created on demand

On open, a session-local temporary table copy is created from a global
TABLE_SHARE. Let us refer to the former as "local data table of GTT",
and the latter as "global metadata table of GTT".

There is a number of cases, when a global metadata table is opened
instead, like ALTER, DROP, SHOW CREATE

A local data table holds:

1. A reference to that share, and holds the increased
tdc reference count.
2. An explicit MDL lock to the duration of local copy's
existence.

While at least one local data table exists
(2) guarantees that ALTER, DROP or RENAME will not happen.
(1) guarantees that a global metadata table will not be flushed

At an implementation level, a local data table is a temporary table,
invisible for a user and augmented with (1) and (2).

The reference and lock are released upon dropping this local data table,
which happens due to:
a) TRUNCATE TABLE
b) Connection close
c) If ON COMMIT DELETE ROWS is used, then on transaction commit/rollback

## Part 3: ALTER, DROP, RENAME

These operations always open a real global temporary table.

ALTER, RENAME and DROP TABLE require all local data tables to be
destroyed, thus, having no references to a modified/deleted table.
For that, they:
1. acquire an EXCLUSIVE MDL lock. To match oracle behavior,
lock_wait_timeout is 0 in ALTER TABLE.
2. Check that there is no matching local temporary table in the same
connection (which is not guaranteed by 1)

## Part 4 ON COMMIT DELETE ROWS

This clause is assumed by default, i.e. it is implicit.

When ON COMMIT DELETE ROWS, the local data table is dropped on
commit/rollback.

On table open, global_temporary_tables handlerton is injected,
implementing this behavior.

# Limitations

The following is forbidden for GTT:
system versioning
partitioning
fk
ONLINE ALTER
CREATE GLOBAL TEMPORARY under LOCK TABLES
FLUSH TABLE on Global temporary table is no-op for now

# Refactorings, details

1. Extract drop_tmp_table_share (temporary_tables.cc)
2. Extract THD::open_temporary_table_impl (temporary_tables.cc)
3. information_schema support:
 x) "GLOBAL TEMPORARY" type is show in information_schema.tables
 y) an artifical temporary table is hidden from SHOW TABLE STATUS

4. VIEWs are supported.
5. AS SELECT support

 x) Made in Oracle style, so that the data is only inserted in the
 session that creates GTT
 y) ON COMMIT DELETE ROWS inserts the data for real, and then deletes
 the data table on implicit commit

6. CREATE TABLE ... LIKE is supported.

7. Replication support
 x) Set share->table_creation_was_logged to 0 to make the table ignored
 for replication.
 y) Statements with GTT involved will be logged in Row-based style
 (RBR)
 z) Global temporary table creation and alter/drop will be logged.
2025-08-12 17:54:52 +02:00
..
charsets Fix remaining typos 2025-04-29 11:18:00 +10:00
CMakeLists.txt MDEV-32923: drop errmsg-utf8.txt from packaging 2023-12-18 14:15:15 +11:00
errmsg-utf8.txt MDEV-35915 Implement Global temporary tables 2025-08-12 17:54:52 +02:00
insert_translations_into_errmsg.py A procedure and script to speed up translation of MariaDB error messages to a new language 2023-07-20 11:16:21 +01:00
README.md Fix remaining typos 2025-04-29 11:18:00 +10:00

A quicker way for adding new language translations to the errmsg-utf8.txt file

Summary

To generate a new language translation of MariaDB use the following pull request (PR) as a template for your work:

You will notice as part of your translation work, you will have to add your language translations to the file sql/share/errmsg-utf8.txt which is found in the current directory. This file is long with many sections which can make the translation work tedious. In this README, we explain a procedure and provide a script insert_translations_into_errmsg.py that cuts down the amount of tedium in accomplishing the task.

Procedure

  1. Start by grepping out all the english translations from errmsg-utf8.txt using the following grep command, and redirecting the output to a file:

    grep -P "^\s*eng\s" errmsg-utf8.txt > all_english_text_in_errmsg-utf8.txt

  2. Next use Google translate to obtain a translation of this file. Google translate provides the ability to upload whole files for translation. For example, this technique was used to obtain Swahili translations which yielded a file with output similar to the below (output is truncated for clarity):

    sw "hashchk" sw "isamchk" sw "LA" sw "NDIYO" sw "Haiwezi kuunda faili '% -.200s' (kosa: %iE)" sw "Haiwezi kuunda jedwali %s.%s (kosa: %iE)" sw "Haiwezi kuunda hifadhidata '% -.192s' (kosa: %iE)" sw "Haiwezi kuunda hifadhidata '% -.192s'; hifadhidata ipo"

Note that Google translate removes the leading whitespace in the translation file it generates. DO NOT add that leading whitespace back!

  1. Give the translated file an appropriate name (e.g. all_swahili_text_in_errmsg-utf8.txt) and store it in the same directory with errmsg-utf8.txt and all_english_text_in_errmsg-utf8.txt. These 3 files will be used by the script insert_translations_into_errmsg.py.

  2. Proof check the auto-translations in the file you downloaded from Google translate. Note that Google might omit formatting information that will cause the compilation of MariaDB to fail, so pay attention to these.

  3. Reintegrate these translations into the errmsg-utf8.txt by running the insert_translations_into_errmsg.py script as follows:

    chmod ugo+x insert_translations_into_errmsg.py # Make the script executable if it is not.

    ./insert_translations_into_errmsg.py <errmsg-utf8.txt file>

    For example, for the swahili translation, we ran the following:

    ./insert_translations_into_errmsg.py errmsg-utf8.txt all_english_text_in_errmsg-utf8.txt all_swahili_text_in_errmsg-utf8.txt

    The script uses the errmsg-utf8.txt file and the grepped english file to keep track of each new translation. It then creates a file in the same directory as errmsg-utf8.txt with the name errmsg-utf8-with-new-language.txt.

  4. Check that the reintegration of the new translations into errmsg-utf8-with-new-language.txt went OK, and if it did, rename errmsg-utf8-with-new-language.txt to errmsg-utf8.txt:

    mv errmsg-utf8-with-new-language.txt errmsg-utf8.txt

  5. In the header of errmsg-utf8.txt make sure to add your language long form to short form mapping. E.g. for Swahili, add:

    swahili=sw