summaryrefslogtreecommitdiff
path: root/strings
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-21065 UNIQUE constraint causes a query with string comparison to omit a ↵Alexander Barkov2019-12-162-6/+14
| | | | row in the result set
* crash in string-to-int conversionSergei Golubchik2019-10-191-4/+14
| | | | | | | | | | using a specially crafted strings one could overflow `shift` variable and cause a crash by dereferencing d10[-2147483648] (on a sufficiently old gcc). This is a correct fix and a test case for Bug #29723340: MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ?AST
* Update FSF AddressVicențiu Ciorbaru2019-05-1134-35/+35
| | | | * Update wrong zip-code
* Update FSF addressMichal Schorm2019-05-102-2/+2
| | | | | | | | | | | | | | | This commit is based on the work of Michal Schorm, rebased on the earliest MariaDB version. Th command line used to generate this diff was: find ./ -type f \ -exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \ -exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
* MDEV-17256 Decimal field multiplication bug.bb-5.5-hfAlexey Botchkov2018-10-301-16/+19
| | | | | | We should clear trailing zeroes in frac part. Otherwise that tail is growing quickly and forces unnecessary truncating of arguments.
* MDEV-13459 Warnings, when compiling with gcc-7.xSergei Golubchik2017-10-172-11/+19
| | | | mostly caused by -Wimplicit-fallthrough
* str2decimal: don't return a negative zeroSergei Golubchik2016-12-051-0/+2
|
* potential signedness issueSergei Golubchik2016-09-122-11/+11
| | | | | | different fix for 07a33cdcef: Bug #23296299 : HANDLE_FATAL_SIGNAL (SIG=11) IN MY_TOSORT_UTF32
* MDEV-7973 bigint fail with gcc 5.0Sergei Golubchik2016-07-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | -LONGLONG_MIN is the undefined behavior in C. longlong2decimal() used to do this: int longlong2decimal(longlong from, decimal_t *to) { if ((to->sign= from < 0)) return ull2dec(-from, to); return ull2dec(from, to); and later in ull2dec() (DIG_BASE is 1000000000): static int ull2dec(ulonglong from, decimal_t *to) { for (intg1=1; from >= DIG_BASE; intg1++, from/=DIG_BASE) {} this breaks in gcc-5 at -O3. Here ull2dec is inlined into longlong2decimal. And gcc-5 believes that 'from' in the inlined ull2dec is always a positive integer (indeed, if it was negative, then -from was used instead). So gcc-5 uses *signed* comparison with DIG_BASE. Fix: make a special case for LONGLONG_MIN, don't negate it
* MDEV-8407 Numeric errors, server crash with COLUMN_JSON() on DECIMAL with ↵Oleksandr Byelkin2015-12-101-1/+2
| | | | | | precision > 40 In fact it was error in decimal library (incorrect processing of buffer overflow) invisible from other server parts because of buffer allocation and precision tests.
* Correct length check in my_wc_mb_filename()Jan Lindström2015-12-071-1/+1
|
* MDEV-7649 wrong result when comparing utf8 column with an invalid literalAlexander Barkov2015-04-241-1/+19
|
* decimal: *correct* implementation of ROUND_UP at lastSergei Golubchik2014-10-081-1/+1
|
* fixes for decimal typeSergei Golubchik2014-10-071-1/+5
|
* mysql-5.5.40Sergei Golubchik2014-10-062-5/+5
|\
| * Bug #11755818 : LIKE DOESN'T MATCH WHEN CP932_BIN/SJIS_BINmithun2014-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | COLLATIONS ARE USED. ISSUE : ------- Code points of HALF WIDTH KATAKANA in SJIS/CP932 range from A1 to DF. In function my_wildcmp_mb_bin_impl while comparing such single byte code points, there is a code which compares signed character with unsigned character. Because of this, comparisons of two same code points representing a HALF WIDTH KATAKANA character always fails. Solution: --------- A code point of HALF WIDTH KATAKANA at-least need 8 bits. Promoting the variable from uchar to int will fix the issue. mysql-test/t/ctype_cp932.test: Tests which have conditions LIKE 'STRING PATTERN WITH HALF WIDTH KATAKANA'. strings/ctype-mb.c: A code point of HALF WIDTH KATAKANA at-least need 8 bits. Promoting the variable from uchar to int will fix the issue.
| * Bug#18469276: MOD FOR SMALL DECIMALS FAILSChaithra Reddy2014-07-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: If leading zeroes of fractional part of a decimal number exceeds 45, mod operation on the same fails. Analysis: Currently there is a miscalcultion of fractional part for very small decimals in do_div_mod. For ex: For 0.000(45 times).....3 length of the integer part becomes -5 (for a length of one, buffer can hold 9 digits. Since number of zeroes are 45, integer part becomes 5) and it is negative because of the leading zeroes present in the fractional part. Fractional part is the number of digits present after the point which is 46 and therefore rounded off to the nearest 9 multiple which is 54. So the length of the resulting fractional part becomes 6. Because of this, the combined length of integer part and fractional part exceeds the max length allocated which is 9 and thereby failing. Solution: In case of negative integer value, it indicates there are leading zeroes in fractional part. As a result stop1 pointer should be set not just based on frac0 but also intg0. This is because the detination buffer will be filled with 0's for the length of intg0. strings/decimal.c: Calculate stop1 pointer based on the length of intg0 and frac0.
* | mysql-5.5.39 mergeSergei Golubchik2014-08-024-8/+9
|\ \ | |/ | | | | | | | | | | ~40% bugfixed(*) applied ~40$ bugfixed reverted (incorrect or we're not buggy) ~20% bugfixed applied, despite us being not buggy (*) only changes in the server code, e.g. not cmakefiles
| * Bug#18850241 WRONG COPYRIGHT HEADER IN SOME STRINGS/CTYPE-* FILESErlend Dahl2014-06-233-3/+6
| |
| * Backport from trunk:Tor Didriksen2014-05-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug#18187290 ISSUE WITH BUILDING MYSQL USING CMAKE 2.8.12 We want to upgrade to VS2013 on Windows. In order to do this, we need to upgrade to cmake 2.8.12 This has introduced some incompatibilities for .pdb files, and "make install" no longer works. To reproduce: cmake --build . --target package --config debug The fix: Rather than installing .pdb files for static libraries, we use the /Z7 flag to store symbolic debugging information in the .obj files.
| * Bug #17760379 COLLATIONS WITH CONTRACTIONS BUFFER-OVERFLOW THEMSELVES IN THE ↵Venkata Sidagam2014-01-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FOOT Description: A typo in create_tailoring() causes the "contraction_flags" to be written into cs->contractions in the wrong place. This causes two problems: (1) Anyone relying on `contraction_flags` to decide "could this character be part of a contraction" is 100% broken. (2) Anyone relying on `contractions` to determine the weight of a contraction is mostly broken Analysis: When we are preparing the contraction in create_tailoring(), we are corrupting the cs->contractions memory location which is supposed to store the weights(8k) + contraction information(256 bytes). We started storing the contraction information after the 4k location. This is because of logic flaw in the code. Fix: When we create the contractions, we need to calculate the contraction with (char*) (cs->contractions + 0x40*0x40) from ((char*) cs->contractions) + 0x40*0x40. This makes the "cs->contractions" to move to 8k bytes and stores the contraction information from there. Similarly when we are calculating it for like range queries we need to calculate it from the 8k bytes onwards, this can be done by changing the logic to (const char*) (cs->contractions + 0x40*0x40). And for ucs2 charsets we need to modify the my_cs_can_be_contraction_head() and my_cs_can_be_contraction_tail() to point to 8k+ locations.
* | MDEV-5745 analyze MySQL fix for bug#12368495Alexander Barkov2014-07-281-6/+6
| |
* | Merge 5.3->5.5Alexander Barkov2014-04-231-4/+5
|\ \
| * | MDEV-5338 XML parser accepts malformed dataAlexander Barkov2014-04-231-4/+5
| | |
| * | 5.2 mergeSergei Golubchik2014-03-1627-98/+181
| |\ \
| | * \ 5.1 mergeSergei Golubchik2014-03-1627-98/+181
| | |\ \
| | | * \ mysql-5.1.73 mergeSergei Golubchik2014-03-1527-100/+183
| | | |\ \
* | | | \ \ MySQL-5.5.36 mergeSergei Golubchik2014-02-179-55/+248
|\ \ \ \ \ \ | | |_|_|_|/ | |/| | | | | | | | | | (without few incorrect bugfixes and with 1250 files where only a copyright year was changed)
| * | | | | Updated/added copyright headersMurthy Narkedimilli2014-01-069-10/+10
| | | | | |
| * | | | | Bug #14057034 : WASTED CPU CYCLES IN MY_UTF8_UNI WHEREmithun2013-11-121-35/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RESULTING MY_WC_T RESULT IS NOT USED Issue : handler functions my_ismbchar_utf8, my_well_formed_len_mb for charset utf8 is calling unicode converion function to validate and to find the character length. Because of this, instructions which will convert the utf8 to unicode are executed for no use. A similar issue exist with charset utf8mb4 Solution : reorganized the code such that character validation part of unicode conversion handler is extracted(duplicated) in to separate function. Hence my_ismbchar_utf8, my_well_formed_len_mb will call the new function which only validates and return the length of mb(utf8). A similar fix for charset utf8mb4. strings/ctype-utf8.c: New functions has been added for charset utf8 and utf8mb4 to validate and to get the length of the character.
| * | | | | Bug#16691598 - ORDER BY LOWER(COLUMN) PRODUCES OUT-OF-ORDER RESULTSNeeraj Bisht2013-11-072-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem:- We have created a table with UTF8_BIN collation. In case, when in our query we have ORDER BY clause over a function call we are getting result in incorrect order. Note:the bug is not there in 5.5. Analysis: In 5.5, for UTF16_BIN, we have min and max multi-byte length is 2 and 4 respectively.In make_sortkey(),for 2 byte character character we are assuming that the resultant length will be 2 byte/character. But when we use my_strnxfrm_unicode_full_bin(), we store sorting weights using 3 bytes per character.This result in truncated result. Same thing happen for UTF8MB4, where we have 1 byte min multi-byte and 4 byte max multi-byte.We will accsume resultant data as 1 byte/character, which result in truncated result. Solution:- use strnxfrm(means use of MY_CS_STRNXFRM macro) is used for sort, in which the resultant length is not dependent on source length.
* | | | | | MySQL-5.5.35 mergeSergei Golubchik2014-01-222-1/+6
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Bug 13878021 - WINDOWS PACKAGE THAT INCLUDES .PDB FILES FOR INTERMEDIATE ↵Sreedhar.S2013-10-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | LIBRARIES USED
| * | | | | Bug#16765410 FTS: STACK AROUND THE VARIABLE 'MYSTR' WAS CORRUPTED IN ↵Tor Didriksen2013-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INNOBASE_STRNXFRM my_strnxfrm_win1250ch could write into dest[destlen] i.e. write a byte to the past-the-end of dest.
* | | | | | MDEV-5453 Assertion `src' fails in my_strnxfrm_unicode on GROUP BY MID(..) ↵Alexander Barkov2013-12-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WITH ROLLUP Fixed a wrong assertion.
* | | | | | mysql-5.5.34 mergeSergei Golubchik2013-11-191-2/+2
|\ \ \ \ \ \ | |/ / / / / | | | | | | | | | | | | (some patches reverted, test case added)
| * | | | | Bug#16997513 MY_STRTOLL10 ACCEPTING OVERFLOWED UNSIGNED LONG LONG VALUES AS ↵Joao Gramacho2013-07-311-2/+2
| |\ \ \ \ \ | | | |_|_|/ | | |/| | | | | | | | | | | | | | | | | | | | | NORMAL ONES Merge from mysql-5.1 into mysql-5.5
| | * | | | Bug#16997513 MY_STRTOLL10 ACCEPTING OVERFLOWED UNSIGNED LONG LONG VALUES AS ↵Joao Gramacho2013-07-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NORMAL ONES Problem: ======= It was detected an incorrect behavior of my_strtoll10 function when converting strings with numbers in the following format: "184467440XXXXXXXXXYY" Where XXXXXXXXX > 737095516 and YY <= 15 Samples of problematic numbers: "18446744073709551915" "18446744073709552001" Instead of returning the larger unsigned long long value and setting overflow in the returned error code, my_strtoll10 function returns the lower 64-bits of the evaluated number and did not set overflow in the returned error code. Analysis: ======== Once trying to fix bug 16820156, I've found this bug in the overflow check of my_strtoll10 function. This function, once receiving a string with an integer number larger than 18446744073709551615 (the larger unsigned long long number) should return the larger unsigned long long number and set overflow in the returned error code. Because of a wrong overflow evaluation, the function didn't catch the overflow cases where (i == cutoff) && (j > cutoff2) && (k <= cutoff3). When the overflow evaluation fails, the function return the lower 64-bits of the evaluated number and do not set overflow in the returned error code. Fix: === Corrected the overflow evaluation in my_strtoll10.
| | * | | | Bug#11766191:INVALID MEMORY READ IN DO_DIV_MOD WITH DOUBLY ASSIGNED VARIABLESChaithra Gopalareddy2013-05-221-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug#12608543: CRASHES WITH DECIMALS AND STATEMENT NEEDS TO BE REPREPARED ERRORS Backporting these two fixes to 5.1 Added unittest to test my_decimal construtor and assignment operators sql/my_decimal.h: Added constructor and assignment operators for my_decimal unittest/my_decimal/my_decimal-t.cc: Added test to check constructor and assignment operators for my_decimal
| | * | | | Bug 16395495 - OLD FSF ADDRESS IN GPL HEADERMurthy Narkedimilli2013-03-1918-31/+32
| | | | | |
| | * | | | Updated/added copyright headers.Murthy Narkedimilli2013-02-2557-60/+57
| | | | | |
* | | | | | mysql-5.5.33 mergeSergei Golubchik2013-09-062-22/+26
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Bug #16567381 DATETIME FIELD COMPARISONS DO NOT WORK PROPERLY Venkata Sidagam2013-07-041-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WITH UTF8_UNICODE_CI COLLATION Problem Description: When comparing datetime values with strings, the utf8_unicode_ci collation prevents correct comparisons. Consider the below set of queries, it is not showing any results on a table which has tuples that satisfies the query. But for collation utf8_general_ci it shows one tuple. set names utf8 collate utf8_unicode_ci;; select * from lang where dt='1979-12-09'; Analysis: The comparison function is not chosen in case of collation utf8_unicode_ci. In agg_item_set_converter() because the collation state is having "MY_CS_NONASCII" for collation type "utf8_unicode_ci". The conversion of the collation is happening for the date field. And because of that it is unable to pickup proper compare function(i.e CMP_DATE_WITH_STR). Actually the bug is accidentally introduced by the WL#3759 in 5.5. And in 5.6 it is been fixed by the WL#3664. Fix: I have backported the changes from the file strings/ctype-uca.c which are related to "utf8" introduced by the WL#3664. This change helps in choosing the correct comparison function for all the collations of utf8 charset.
| * | | | | Bug#14834378 ADDRESSSANITIZER BUG IN FILENAME_TO_TABLENAMETor Didriksen2013-06-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport to 5.5 sql/sql_table.cc: gcc asan crashes in filename_to_tablename() on this: memcmp("-@", "#sql", 4) during loading of the innobase plugin
* | | | | | mysql-5.5.32 mergeSergei Golubchik2013-07-166-9/+9
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Fix for Bug 16395495 - OLD FSF ADDRESS IN GPL HEADERMurthy Narkedimilli2013-03-196-9/+9
| | | | | |
* | | | | | mysql-5.5.31 mergeSergei Golubchik2013-05-077-41/+123
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONINGMattias Jonsson2013-01-301-2/+2
| |\ \ \ \ \ | | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to an internal change in the server code in between 5.1 and 5.5 (wl#2649) the hash function used in KEY partitioning changed for numeric and date/time columns (from binary hash calculation to character based hash calculation). Also enum/set changed from latin1 ci based hash calculation to binary hash between 5.1 and 5.5. (bug#11759782). These changes makes KEY [sub]partitioned tables on any of the affected column types incompatible with 5.5 and above, since the calculation of partition id differs. Also since InnoDB asserts that a deleted row was previously read (positioned), the server asserts on delete of a row that is in the wrong partition. The solution for this situation is: 1) The partitioning engine will check that delete/update will go to the partition the row was read from and give an error otherwise, consisting of the rows partitioning fields. This will avoid asserts in InnoDB and also alert the user that there is a misplaced row. A detailed error message will be given, including an entry to the error log consisting of both table name, partition and row content (PK if exists, otherwise all partitioning columns). 2) A new optional syntax for KEY () partitioning in 5.5 is allowed: [SUB]PARTITION BY KEY [ALGORITHM = N] (list_of_cols) Where N = 1 uses the same hashing as 5.1 (Numeric/date/time fields uses binary hashing, ENUM/SET uses charset hashing) N = 2 uses the same hashing as 5.5 (Numeric/date/time fields uses charset hashing, ENUM/SET uses binary hashing). If not set on CREATE/ALTER it will default to 2. This new syntax should probably be ignored by NDB. 3) Since there is a demand for avoiding scanning through the full table, during upgrade the ALTER TABLE t PARTITION BY ... command is considered a no-op (only .frm change) if everything except ALGORITHM is the same and ALGORITHM was not set before, which allows manually upgrading such table by something like: ALTER TABLE t PARTITION BY KEY ALGORITHM = 1 () or ALTER TABLE t PARTITION BY KEY ALGORITHM = 2 () 4) Enhanced partitioning with CHECK/REPAIR to also check for/repair misplaced rows. (Also works for ALTER TABLE t CHECK/REPAIR PARTITION) CHECK FOR UPGRADE: If the .frm version is < 5.5.3 and uses KEY [sub]partitioning and an affected column type then it will fail with an message: KEY () partitioning changed, please run: ALTER TABLE `test`.`t1` PARTITION BY KEY ALGORITHM = 1 (a) PARTITIONS 12 (i.e. current partitioning clause, with the addition of ALGORITHM = 1) CHECK without FOR UPGRADE: if MEDIUM (default) or EXTENDED options are given: Scan all rows and verify that it is in the correct partition. Fail for the first misplaced row. REPAIR: if default or EXTENDED (i.e. not QUICK/USE_FRM): Scan all rows and every misplaced row is moved into its correct partitions. 5) Updated mysqlcheck (called by mysql_upgrade) to handle the new output from CHECK FOR UPGRADE, to run the ALTER statement instead of running REPAIR. This will allow mysql_upgrade (or CHECK TABLE t FOR UPGRADE) to upgrade a KEY [sub]partitioned table that has any affected field type and a .frm version < 5.5.3 to ALGORITHM = 1 without rebuild. Also notice that if the .frm has a version of >= 5.5.3 and ALGORITHM is not set, it is not possible to know if it consists of rows from 5.1 or 5.5! In these cases I suggest that the user does: (optional) LOCK TABLE t WRITE; SHOW CREATE TABLE t; (verify that it has no ALGORITHM = N, and to be safe, I would suggest backing up the .frm file, to be used if one need to change to another ALGORITHM = N, without needing to rebuild/repair) ALTER TABLE t <old partitioning clause, but with ALGORITHM = N>; which should set the ALGORITHM to N (if the table has rows from 5.1 I would suggest N = 1, otherwise N = 2) CHECK TABLE t; (here one could use the backed up .frm instead and change to a new N and run CHECK again and see if it passes) and if there are misplaced rows: REPAIR TABLE t; (optional) UNLOCK TABLES;
| * | | | | BUG#14303860 - EXECUTING A SELECT QUERY WITH TOO Neeraj Bisht2013-01-146-42/+123
| |\ \ \ \ \ | | |/ / / / | | | | | | | | | | | | | | | | | | MANY WILDCARDS CAUSES A SEGFAULT Back port from 5.6 and trunk
| | * | | | BUG#14303860 - EXECUTING A SELECT QUERY WITH TOO Neeraj Bisht2013-01-146-40/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MANY WILDCARDS CAUSES A SEGFAULT Back port from 5.6 and trunk
View Lorry Controller Status