Monty, On Thu, Apr 16, 2020 at 3:32 PM Michael Widenius <michael.widenius@gmail.com> wrote:
ALTER PARTITION shadow files: #sql-shadow-'original_table_name'
Please, add a thread_id here at the end. normally MDL should ensure that no two threads can have a shadow for the same table at the same time, but we have enough bugs as it is to introduce another vector when two threads can overwrite each other temp files.
That would make the file name even longer and I am not sure what happens if we table names goes much over NAME_LEN. I don't have time just now to check for possible name overruns (I think it should be save as most engines are using FN_REFLEN, but better safe than sorry.
FN_REFLEN limits the path name to only 511 or 512 bytes. When I started using GNU/Linux in 1993, the maximum path name length was 4095 or 4096 bytes. Already back then, extfs or xiafs or something supported up to 255 bytes per path name component (name in a directory). The sad matter of fact is that with the filename-safe encoding (my_charset_filename) of MySQL 5.1, we can use up to 5 ASCII bytes per character. We can already easily blow the 255-byte limit of ext4fs or similar by creating a table, partition, and subpartition name consisting of (say) 64 $ characters (which will be encoded as @0024). The complete filename would be something like @0024#P#@0024#SP#@0024.frm (add more sequences of @0024). This could have been made a little worse in MySQL 5.1. In the old days (4.1 and 5.0), AFAIU we stored the file name in UTF-8 encoding (up to 3*64=192 bytes for database name, and 3*3*64+some bytes for table,partition,subpartition name). Also that would easily exceed the 255-byte path component limit of the Linux extfs and its successors. Side note: Windows NTFS uses UTF-16 encoding for file names and can support up to 32768 characters per path component when using some extension. But the selection of disallowed characters in file names is larger than the *nix one ('/' and NUL). So, the reasons for introducing my_charset_filename might not have gone completely away. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation