mariadb

Commit Graph

Author	SHA1	Message	Date
Rohit Kalhans	fe9352454f	BUG#11765650 - 58637: MARK UPDATES THAT DEPEND ON ORDER OF TWO KEYS UNSAFE Description: When the table has more than one unique or primary key, INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows on master and slave. Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique key as unsafe therefore the event will be logged in row format if it is available (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown.	14 years ago
Jon Olav Hauglid	1f5051d9f2	Bug#13833438: ERROR CODES MUST HAVE SAME VALUE ACROSS MYSQL VERSIONS Pre-requisite patch. Add end-of-file marker to 5.5 version of errmsg-utf8.txt.	14 years ago
Jon Olav Hauglid	f270614180	Bug#13833438: ERROR CODES MUST HAVE SAME VALUE ACROSS MYSQL VERSIONS Pre-requisite patch. Add end-of-file marker to 5.5 version of errmsg-utf8.txt.	14 years ago
Annamalai Gurusami	c1615df32c	Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML There are two threads. In one thread, dml operation is going on involving cascaded update operation. In another thread, alter table add foreign key constraint is happening. Under these circumstances, it is possible for the dml thread to access a dict_foreign_t object that has been freed by the ddl thread. The debug sync test case provides the sequence of operations. Without fix, the test case will crash the server (because of newly added assert). With fix, the alter table stmt will return an error message. rb:947 approved by Jimmy Yang	14 years ago
Annamalai Gurusami	152bb4c17d	Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML There are two threads. In one thread, dml operation is going on involving cascaded update operation. In another thread, alter table add foreign key constraint is happening. Under these circumstances, it is possible for the dml thread to access a dict_foreign_t object that has been freed by the ddl thread. The debug sync test case provides the sequence of operations. Without fix, the test case will crash the server (because of newly added assert). With fix, the alter table stmt will return an error message. rb:947 approved by Jimmy Yang	14 years ago
Rohit Kalhans	31c990ca57	BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrieved from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table based on the rows selected from another table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe. sql/share/errmsg-utf8.txt: Added new warning messages. sql/sql_base.cc: -Created function to check statements that write to tables with auto_increment column and has select. -Marked all the statements that write to a table with auto_increment column based on rows fetched from other table(s) as unsafe. sql/sql_table.cc: mark CREATE TABLE[with auto_increment column] as unsafe.	14 years ago
Rohit Kalhans	4f7e4c9d1b	BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrieved from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table based on the rows selected from another table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe.	14 years ago
Rohit Kalhans	b7430d73e4	Backout the patch for bug#11758263.	14 years ago
Rohit Kalhans	9153fddf58	Backout the patch for bug#11758263.	14 years ago
Rohit Kalhans	de85a60049	BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrived from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe. sql/share/errmsg-utf8.txt: Added new Warning messages sql/sql_base.cc: created a new function that checks for select + write on a autoinc table made all such statements to be unsafe. sql/sql_parse.cc: made create autoincremnet tabble + select unsafe	14 years ago
Rohit Kalhans	6df5a61d2e	BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrived from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe.	14 years ago
Andrei Elkin	f91c2d33f4	bug#3593869-64035 A follow-up patch corrects max sizes of printed strings and changes llstr() to %lld. Credits go to Davi who provided a great feedback. sql/share/errmsg-utf8.txt: Max size for the whole message is 512 so a part of - like '%-.512s' should be less, reduction to 320 is safe and with good chances won't cut off a part of a rather log message in Last_IO_Error = 'Got fatal error 1236 ...' sql/sql_repl.cc: llstr() is replaced by %lld.	14 years ago
Andrei Elkin	a7f1c7d955	bug#3593869-64035 A follow-up patch corrects max sizes of printed strings and changes llstr() to %lld. Credits go to Davi who provided a great feedback.	14 years ago
Andrei Elkin	7cdd7a7493	BUG#13593869 - 64035: SEVERAL ERRORS IN COM_BINLOG_DUMP/MYSQL_BINLOG_SEND CRASH THE SERVER The server crashes when receiving a COM_BINLOG_DUMP command with a position of 0 or larger than the file size. The execution proceeds to an error block having the last read replication coordinates pointer be NULL and its dereferencing crashed the server. Fixed with making "public" previously used only for heartbeat coordinates. mysql-test/extra/rpl_tests/rpl_start_stop_slave.test: regression test for bug#3593869-64035 is added. mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result: results updated (error mess format is changed). mysql-test/suite/rpl/r/rpl_log_pos.result: results updated (error mess format is changed). mysql-test/suite/rpl/r/rpl_manual_change_index_file.result: results updated (error mess format is changed). mysql-test/suite/rpl/r/rpl_packet.result: results updated (error mess format is changed). mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result: results updated (error mess format is changed). mysql-test/suite/rpl/t/rpl_stm_start_stop_slave.test: Slave is stopped by bug#3593869-64035 tests so -let $rpl_only_running_threads= 1 is set prior to rpl_end. sql/share/errmsg-utf8.txt: Increasing the max length of explanatory message to 512. sql/sql_repl.cc: Making `coord' to carry the last read from binlog event coordinates regardless of heartbeat. Renaming, small cleanup and simplifying the code after if (coord) becomes unnecessary. Adding yet another 3rd pair of coordinates - the starting replication - into error text.	14 years ago
Andrei Elkin	1552531616	BUG#13593869 - 64035: SEVERAL ERRORS IN COM_BINLOG_DUMP/MYSQL_BINLOG_SEND CRASH THE SERVER The server crashes when receiving a COM_BINLOG_DUMP command with a position of 0 or larger than the file size. The execution proceeds to an error block having the last read replication coordinates pointer be NULL and its dereferencing crashed the server. Fixed with making "public" previously used only for heartbeat coordinates.	14 years ago
Sergei Golubchik	2ec0f46b88	query cache sysvar fixes sql/share/errmsg-utf8.txt: correct the error message, as query_cache_type variable is not read-ony anymore sql/sql_cache.cc: the caller should verify that query cache resize is possible, before trying it sql/sys_vars.cc: * test if qc resize is possible in the sysvar on_check() funntion, not in the on_update() function. * use the error message that better describes the problem	14 years ago
Sergei Golubchik	2ccf247e93	after merge changes: * rename all debugging related command-line options and variables to start from "debug-", and made them all OFF by default. * replace "MySQL" with "MariaDB" in error messages * "Cast ... converted ... integer to it's ... complement" is now a note, not a warning * @@query_cache_strip_comments now has a session scope, not global.	14 years ago
Marko Mäkelä	0c775ea96f	Update the German error message translations (by Stefan Hinz) and fix some Swedish too.	14 years ago
Marko Mäkelä	4db6d87789	Update the German error message translations (by Stefan Hinz) and fix some Swedish too.	14 years ago
Andrei Elkin	593c9457cd	Bug#11747416 : 32228 A disk full makes binary log corrupt Binary log of master can get a partially logged event if the server runs out of disk space and, while waiting for some space to be freed, is shut down (or crashes). If the server is not stopped, it will just wait endlessly for space to be freed, thus no partial event anomaly occurs. The restarted master server has had a dubious policy to send the incomplete event to slave which it apparently can't handle. Although an error was printed out the fact of sending with unclear error message is a source of confusion. Actually the problem of presence an incomplete event in the binary log was already fixed by WL 5493 (which was merged to our current trunk branch, major version 5.6). The fix makes the server truncate the binary log on server restart and recovery. However 5.5 master can't do that. So the current issue is a problem of sending incomplete events to the slave by 5.5 master. It is fixed in this patch by changing the policy so that only complete events are pushed by the dump thread to the IO thread. In addition, the error text that master sends to the slave when an incomplete event is found, now states that incomplete event may have been caused by an out-of-disk space situation and provides coordinates of the first and the last event bytes read. mysql-test/std_data/bug11747416_32228_binlog.000001: a binlog is added with the last event written partly. mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result: new result file is added. mysql-test/suite/rpl/r/rpl_log_pos.result: results updated. mysql-test/suite/rpl/r/rpl_manual_change_index_file.result: results updated. mysql-test/suite/rpl/r/rpl_packet.result: results updated. mysql-test/suite/rpl/t/rpl_cant_read_event_incident.test: regression test for bug#11747416 : 32228 A disk full makes binary log corrupt is added. sql/share/errmsg-utf8.txt: Increasing the explanatory part of ER_MASTER_FATAL_ERROR_READING_BINLOG error message twice in order to fit to the updated version which carries some more info. sql/sql_repl.cc: Error text indicating a failure of reading from binlog that master delivers to the slave is made more clear; A policy to regard a partial event to send it out to the slave anyway is removed.	14 years ago
Andrei Elkin	b426043b7c	Bug#11747416 : 32228 A disk full makes binary log corrupt Binary log of master can get a partially logged event if the server runs out of disk space and, while waiting for some space to be freed, is shut down (or crashes). If the server is not stopped, it will just wait endlessly for space to be freed, thus no partial event anomaly occurs. The restarted master server has had a dubious policy to send the incomplete event to slave which it apparently can't handle. Although an error was printed out the fact of sending with unclear error message is a source of confusion. Actually the problem of presence an incomplete event in the binary log was already fixed by WL 5493 (which was merged to our current trunk branch, major version 5.6). The fix makes the server truncate the binary log on server restart and recovery. However 5.5 master can't do that. So the current issue is a problem of sending incomplete events to the slave by 5.5 master. It is fixed in this patch by changing the policy so that only complete events are pushed by the dump thread to the IO thread. In addition, the error text that master sends to the slave when an incomplete event is found, now states that incomplete event may have been caused by an out-of-disk space situation and provides coordinates of the first and the last event bytes read.	14 years ago
Rohit Kalhans	586c0c0ef6	BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN\|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments. **** BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN\|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments. mysql-test/extra/rpl_tests/rpl_insert_duplicate.test: Test removed: Added the test to rpl.rpl_insert_ignore.test ** Test removed: the test is redundant as the same is being tested in rpl.rpl_insert_ignore. mysql-test/extra/rpl_tests/rpl_insert_id.test: Warnings disabled for the unsafe statements. mysql-test/extra/rpl_tests/rpl_insert_ignore.test: 1. Disabled warnings while for unsafe statements 2. As INSERT...IGNORE is an unsafe statement, an insert ignore not changing any rows, will not be logged in the binary log, in the ROW and MIXED modes. It will however be logged in STATEMENT mode. mysql-test/r/commit_1innodb.result: updated result file ** updated result file mysql-test/suite/binlog/r/binlog_stm_blackhole.result: Updated result file. mysql-test/suite/binlog/r/binlog_unsafe.result: updated result file mysql-test/suite/binlog/t/binlog_unsafe.test: added tests for the statements marked as unsafe. mysql-test/suite/rpl/r/rpl_insert_duplicate.result: File Removed :Result file of rpl_insert_duplicate, which has been removed. mysql-test/suite/rpl/r/rpl_insert_ignore.result: Added the content of rpl.rpl_insert_duplicate here. mysql-test/suite/rpl/r/rpl_insert_select.result: Result file removed as the corresponding test has beenn removed. mysql-test/suite/rpl/r/rpl_known_bugs_detection.result: Updated result file. mysql-test/suite/rpl/t/rpl_insert_duplicate.test: File Removed: this was a wrapper for rpl.rpl_insert_duplicate.test, which has been removed. mysql-test/suite/rpl/t/rpl_insert_select.test: File Removed: This test became redundant after this fix, This test showed how INSERT IGNORE...SELECT break replication, which has been handled in this fix. mysql-test/suite/rpl/t/rpl_known_bugs_detection.test: Since all the tests are statement based bugs are being tested, having mixed format forces the event to be written in row format. When the statement and causes the test to fail as certain known bugs do not occur when the even is logged in row format. sql/share/errmsg-utf8.txt: added 6 new Warning messages. **** added 6 new Warning messages. sql/sql_lex.cc: Added 6 new error Identifier [ER_BINLOG_STMT_UNSAFEE_] sql/sql_lex.h: Added 6 new BINLOG_STMT_UNSAFE_ enums to identify the type of unsafe statement dealt with in this bug. ****** Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug. sql/sql_parse.cc: added check for specific queries and marked them as unsafe. ****** added check for specific queries and marked them as unsafe.	14 years ago
Rohit Kalhans	b140784fbc	BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN\|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments. ****** BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN\|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments.	14 years ago
Marko Mäkelä	247ada63af	Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w with the fix of Bug#12704861 Corruption after a crash during BLOB update but not merged to mysql-5.5 and upwards. In the Barracuda formats, the clustered index record no longer contains a prefix of off-page columns. Because of this, the undo log must contain these prefixes, so that purge and multi-versioning will continue to work. However, this also means that an undo log record can become too big to fit in an undo log page. (It is a limitation of the undo log that undo records cannot span across multiple pages.) In case the checks for undo log size fail when CREATE TABLE or CREATE INDEX is executed, we need a fallback that blocks a modification operation when the undo log record would exceed the maximum size. trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback(). Define the trx_t parameter only in debug builds. trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func(). Pass the trx_t parameter only in debug builds. trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end(). Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop as a while loop for clarity. trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func(). Pass the trx_t parameter only in debug builds. trx_undo_erase_page_end(): Return TRUE if the page was non-empty to begin with. Refuse to erase empty pages. trx_undo_report_row_operation(): If the page for which the undo log was too big was empty, free the undo page and return DB_TOO_BIG_RECORD. rb:749 approved by Inaam Rana	14 years ago
Marko Mäkelä	4c57188c9c	Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w with the fix of Bug#12704861 Corruption after a crash during BLOB update but not merged to mysql-5.5 and upwards. In the Barracuda formats, the clustered index record no longer contains a prefix of off-page columns. Because of this, the undo log must contain these prefixes, so that purge and multi-versioning will continue to work. However, this also means that an undo log record can become too big to fit in an undo log page. (It is a limitation of the undo log that undo records cannot span across multiple pages.) In case the checks for undo log size fail when CREATE TABLE or CREATE INDEX is executed, we need a fallback that blocks a modification operation when the undo log record would exceed the maximum size. trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback(). Define the trx_t parameter only in debug builds. trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func(). Pass the trx_t parameter only in debug builds. trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end(). Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop as a while loop for clarity. trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func(). Pass the trx_t parameter only in debug builds. trx_undo_erase_page_end(): Return TRUE if the page was non-empty to begin with. Refuse to erase empty pages. trx_undo_report_row_operation(): If the page for which the undo log was too big was empty, free the undo page and return DB_TOO_BIG_RECORD. rb:749 approved by Inaam Rana	14 years ago
Jimmy Yang	95fa7fab3b	Fix bug #11830883 , SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES. Also addressed issues in bug #11745133, where we could mark a table corrupted instead of crashing the server when found a corrupted buffer/page if the table created with innodb_file_per_table on.	15 years ago
Jimmy Yang	177d8b0c12	Fix bug #11830883 , SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES. Also addressed issues in bug #11745133, where we could mark a table corrupted instead of crashing the server when found a corrupted buffer/page if the table created with innodb_file_per_table on.	15 years ago
Mats Kindahl	cf5e5f837a	Merging into mysql-5.5.16-release.	15 years ago
Mats Kindahl	ee789c28b4	Merging into mysql-5.5.16-release.	15 years ago
Dmitry Shulga	644db66446	Fixed Bug#12621017 - CRASH IF A SP VARIABLE IS USED IN THE LIMIT CLAUSE OF A SET STATEMENT. Server built with debug asserts, without debug crashes if a user tries to run a stored procedure that constains query with subquery that include either LIMIT or LIMIT OFFSET clauses. The problem was that Item::fix_fields() was not called for the items representing LIMIT or OFFSET clauses. The solution is to call Item::fix_fields() right before evaluation in st_select_lex_unit::set_limit(). mysql-test/r/sp.result: Added testcase result for bug#12621017. Updated testcase result for bug 11918. mysql-test/t/sp.test: Added testcase for bug#12621017. Addressed review comments for Bug 11918 (added tests for use LIMIT at stored function). sql/item.h: Addressed review comments for Bug 11918. sql/share/errmsg-utf8.txt: Addressed review comments for Bug 11918. sql/sp_head.cc: Addressed review comments for Bug 11918. sql/sql_lex.cc: Added call fix_fields() for item just before its evaluation. sql/sql_yacc.yy: Addressed review comments for Bug 11918.	15 years ago
Dmitry Shulga	28bed7d92b	Fixed Bug#12621017 - CRASH IF A SP VARIABLE IS USED IN THE LIMIT CLAUSE OF A SET STATEMENT. Server built with debug asserts, without debug crashes if a user tries to run a stored procedure that constains query with subquery that include either LIMIT or LIMIT OFFSET clauses. The problem was that Item::fix_fields() was not called for the items representing LIMIT or OFFSET clauses. The solution is to call Item::fix_fields() right before evaluation in st_select_lex_unit::set_limit().	15 years ago
Jimmy Yang	9e2b7fa7d5	Implement worklog #5743 InnoDB: Lift the limit of index key prefixes. With this change, the index prefix column length lifted from 767 bytes to 3072 bytes if "innodb_large_prefix" is set to "true". rb://603 approved by Marko	15 years ago
Jimmy Yang	bd708b4240	Implement worklog #5743 InnoDB: Lift the limit of index key prefixes. With this change, the index prefix column length lifted from 767 bytes to 3072 bytes if "innodb_large_prefix" is set to "true". rb://603 approved by Marko	15 years ago
Jon Olav Hauglid	0db0e64f33	Bug #11755431 (former 47205) MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT SUPPORTING NATIVE REPAIR Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue 'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the tables are compatible with the current version of MySQL. Any tables that are found incompatible are then upgraded using 'REPAIR TABLE'. The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'. This caused any such tables to be left incompatible. As a result such tables were not properly fixed by the mysql_upgrade tool. This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return a different error message if the engine does not support REPAIR. Instead of "Table upgrade required. Please do "REPAIR TABLE ..." it will report "Table rebuild required. Please do "ALTER TABLE ... FORCE ..." Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of 'REPAIR TABLE' in these cases. This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table. This change should be reflected in the documentation. Before this patch, 'ALTER TABLE ... FORCE' was unused (See Bug#11746162) Test case added to mysqlcheck.test client/mysqlcheck.c: Changed mysqlcheck to do 'ALTER TABLE ... FORCE' if 'CHECK TABLE FOR UPGRADE' reports ER_TABLE_NEEDS_REBUILD and not ER_TABLE_NEEDS_UPGRADE. mysql-test/r/mysqlcheck.result: Added regression test. mysql-test/std_data/bug47205.frm: InnoDB 5.0 FRM which contains a varchar primary key using utf8_general_ci. This is an incompatible FRM for 5.5. mysql-test/t/mysqlcheck.test: Added regression test. sql/handler.h: Added new HA_CAN_REPAIR flag. sql/share/errmsg-utf8.txt: Added new error message ER_TABLE_NEEDS_REBUILD sql/sql_admin.cc: Changed 'CHECK TABLE FOR UPDATE' to give ER_TABLE_NEEDS_REBUILD instead of ER_TABLE_NEEDS_UPGRADE if the engine does not support REPAIR (as indicated by the new HA_CAN_REPAIR flag). sql/sql_lex.h: Remove unused ALTER_FORCE flag. sql/sql_yacc.yy: Make sure ALTER TABLE ... FORCE recreates the table by setting the ALTER_RECREATE flag as the ALTER_FORCE flag was unused. storage/archive/ha_archive.h: Added new HA_CAN_REPAIR flag to Archive storage/csv/ha_tina.h: Added new HA_CAN_REPAIR flag to CSV storage/federated/ha_federated.h: Added new HA_CAN_REPAIR flag to Federated storage/myisam/ha_myisam.cc: Added new HA_CAN_REPAIR flag to MyISAM	15 years ago
Jon Olav Hauglid	984988cfbd	Bug #11755431 (former 47205) MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT SUPPORTING NATIVE REPAIR Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue 'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the tables are compatible with the current version of MySQL. Any tables that are found incompatible are then upgraded using 'REPAIR TABLE'. The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'. This caused any such tables to be left incompatible. As a result such tables were not properly fixed by the mysql_upgrade tool. This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return a different error message if the engine does not support REPAIR. Instead of "Table upgrade required. Please do "REPAIR TABLE ..." it will report "Table rebuild required. Please do "ALTER TABLE ... FORCE ..." Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of 'REPAIR TABLE' in these cases. This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table. This change should be reflected in the documentation. Before this patch, 'ALTER TABLE ... FORCE' was unused (See Bug#11746162) Test case added to mysqlcheck.test	15 years ago
Jorgen Loland	d1d166875a	BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL UPDATES THE TABLE ENTRIES (formerly 55385) BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND IF A TABLE IS UPDATED TWICE (formerly 57373) If multiple-table update updates a row through two aliases and the first update physically moves the row, the second update will fail to locate the row. This results in different errors depending on storage engine: * MyISAM: Got error 134 from storage engine * InnoDB: Can't find record in 'tbl' None of these errors accurately describe the problem. Furthermore, since MyISAM is non-transactional, the update executed first will be performed while the second will not. In addition, for two equal multiple-table update statements, one could succeed and the other fail based on whether or not the record actually moved or not. This was inconsistent. Two update operations may physically move a row: 1) Update of a column in a clustered primary key 2) Update of a column used to calculate which partition the row belongs to BUG#11764529 is about case 1) above, BUG#11762751 was about case 2). The fix for these bugs is to return with an error if multiple-table update is about to: a) Update a table through multiple aliases, and b) Perform an update that may physically more the row in at least one of these aliases This avoids * partial updates as described for MyISAM above, * provides the same error message that describes the actual problem for all SEs * inconsistent behavior where a statement fails or succeeds based on e.g. the partitioning algorithm of the table. mysql-test/r/multi_update.result: Add test for bug#57373 mysql-test/r/multi_update_innodb.result: Add test for bug#57373 mysql-test/r/partition.result: Add test for bug#55385 mysql-test/t/multi_update.test: Add test for bug#57373 mysql-test/t/multi_update_innodb.test: Add test for bug#57373 mysql-test/t/partition.test: Add test for bug#55385 sql/handler.cc: Translate handler error HA_ERR_RECORD_DELETED to server error sql/share/errmsg-utf8.txt: New error message for multi-table update where the same table is updated multiple times. sql/sql_update.cc: Add function unsafe_key_update()	15 years ago
Jorgen Loland	44b41979bd	BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL UPDATES THE TABLE ENTRIES (formerly 55385) BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND IF A TABLE IS UPDATED TWICE (formerly 57373) If multiple-table update updates a row through two aliases and the first update physically moves the row, the second update will fail to locate the row. This results in different errors depending on storage engine: * MyISAM: Got error 134 from storage engine * InnoDB: Can't find record in 'tbl' None of these errors accurately describe the problem. Furthermore, since MyISAM is non-transactional, the update executed first will be performed while the second will not. In addition, for two equal multiple-table update statements, one could succeed and the other fail based on whether or not the record actually moved or not. This was inconsistent. Two update operations may physically move a row: 1) Update of a column in a clustered primary key 2) Update of a column used to calculate which partition the row belongs to BUG#11764529 is about case 1) above, BUG#11762751 was about case 2). The fix for these bugs is to return with an error if multiple-table update is about to: a) Update a table through multiple aliases, and b) Perform an update that may physically more the row in at least one of these aliases This avoids * partial updates as described for MyISAM above, * provides the same error message that describes the actual problem for all SEs * inconsistent behavior where a statement fails or succeeds based on e.g. the partitioning algorithm of the table.	15 years ago
Tor Didriksen	c711ce6726	Bug #36022 please log more information about "Sort aborted" queries Write an additional warning message to the server log, explaining why a sort operation is aborted. The output in mysqld.err will look something like: 110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of memory (Needed 24 bytes) 110127 15:07:54 [ERROR] mysqld: Out of sort memory, consider increasing server sort buffer size 110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of sort memory, consider increasing server sort buffer size 110127 15:07:54 [ERROR] mysqld: Sort aborted: Incorrect number of arguments for FUNCTION test.f1; expected 0, got 1 If --log-warn=2 is enabled, we output information about host/user/query as well. include/my_sys.h: Update comment for ME_NOREFRESH mysql-test/include/mtr_warnings.sql: Remove global filtering of "Out of sort memory", let each individual test set it instead. mysql-test/r/filesort_debug.result: New test case. mysql-test/r/order_by.result: Ignore "Out of memory" for this test. mysql-test/t/filesort_debug.test: New test case. mysql-test/t/order_by.test: Ignore "Out of memory" for this test. sql/filesort.cc: Output an explanation using the error message from the THD Diagnostics_area. sql/protocol.cc: Do not DBUG_RETURN(function_call_with DBUG_RETURN) as it messes up the call stack in the debug output. sql/share/errmsg-utf8.txt: Change error message for "Out of sort memory" sql/unireg.h: Remove unused/confusing ERRMAPP macro.	15 years ago
Tor Didriksen	207e5321bb	Bug #36022 please log more information about "Sort aborted" queries Write an additional warning message to the server log, explaining why a sort operation is aborted. The output in mysqld.err will look something like: 110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of memory (Needed 24 bytes) 110127 15:07:54 [ERROR] mysqld: Out of sort memory, consider increasing server sort buffer size 110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of sort memory, consider increasing server sort buffer size 110127 15:07:54 [ERROR] mysqld: Sort aborted: Incorrect number of arguments for FUNCTION test.f1; expected 0, got 1 If --log-warn=2 is enabled, we output information about host/user/query as well.	15 years ago
Alfranio Correia	3f5a9c7ea0	BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the stmt-cache and the trx-cache. This means that the resource used is twice the amount expected/defined by the user. The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the trx-cache is used. This behavior does not allow to distinguish which cache may be harming performance due to the extra disk accesses and needs to have its in-memory cache increased. To fix the problem, we introduced two new options and status variables related to the stmt-cache: Options: . binlog_stmt_cache_size . max_binlog_stmt_cache_size Status Variables: . binlog_stmt_cache_use . binlog_stmt_cache_disk_use So there are . binlog_cache_size that defines the size of the transactional cache for updates to transactional engines for the binary log. . binlog_stmt_cache_size that defines the size of the statement cache for updates to non-transactional engines for the binary log. . max_binlog_cache_size that sets the total size of the transactional cache. . max_binlog_stmt_cache_size that sets the total size of the statement cache. . binlog_cache_use that identifies the number of transactions that used the temporary transactional binary log cache. . binlog_cache_disk_use that identifies the number of transactions that used the temporary transactional binary log cache but that exceeded the value of binlog_cache_size. . binlog_stmt_cache_use that identifies the number of statements that used the temporary non-transactional binary log cache. . binlog_stmt_cache_disk_use that identifies the number of statements that used the temporary non-transactional binary log cache but that exceeded the value of binlog_stmt_cache_size. include/my_sys.h: Updated message on disk_writes' usage. mysql-test/extra/binlog_tests/binlog_cache_stat.test: Updated the test case and added code to check the new status variables binlog_stmt_cache_use and binlog_stmt_cache_disk_use. mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test: Updated the test case to use the new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size. mysql-test/r/mysqld--help-notwin.result: Updated the result file. mysql-test/suite/binlog/r/binlog_mixed_cache_stat.result: Updated the result file. mysql-test/suite/binlog/r/binlog_row_cache_stat.result: Updated the result file. mysql-test/suite/binlog/r/binlog_stm_cache_stat.result: Updated the result file. mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result: Update the result file. mysql-test/suite/rpl/r/rpl_row_binlog_max_cache_size.result: Update the result file. mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result: Updated the result file. mysql-test/suite/sys_vars/inc/binlog_stmt_cache_size_basic.inc: Added a test case to check the binlog_stmt_cache_size. mysql-test/suite/sys_vars/r/binlog_stmt_cache_size_basic_32.result: Updated the result file. mysql-test/suite/sys_vars/r/binlog_stmt_cache_size_basic_64.result: Updated the result file. mysql-test/suite/sys_vars/r/max_binlog_stmt_cache_size_basic.result: Updated the result file. mysql-test/suite/sys_vars/t/binlog_stmt_cache_size_basic_32.test: Added a test case to check the binlog_stmt_cache_size. mysql-test/suite/sys_vars/t/binlog_stmt_cache_size_basic_64.test: Added a test case to check the binlog_stmt_cache_size. mysql-test/suite/sys_vars/t/max_binlog_cache_size_func-master.opt: Removed because there is no test case max_binlog_cache_size_func. mysql-test/suite/sys_vars/t/max_binlog_stmt_cache_size_basic.test: Added a test case to check the system variable max_binlog_stmt_cache_size. sql/log.cc: There two main changes in here: . Changed the set_write_error() as an error message is set according to the type of the cache. . Created the function set_binlog_cache_info where references to the appropriate status and system variables are set and the server can smoothly compute statistics and set the maximum size for each cache. sql/log.h: Changed the signature of the function in order to identify the error message to be printed out as there is a different error code for each type of cache. sql/mysqld.cc: Added new status variables binlog_stmt_cache_use and binlog_stmt_cache_disk_use. sql/mysqld.h: Added new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size. sql/share/errmsg-utf8.txt: Added new error message related to the statement cache. sql/sys_vars.cc: Added new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size.	15 years ago
Alfranio Correia	bf2c66d4a7	BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the stmt-cache and the trx-cache. This means that the resource used is twice the amount expected/defined by the user. The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the trx-cache is used. This behavior does not allow to distinguish which cache may be harming performance due to the extra disk accesses and needs to have its in-memory cache increased. To fix the problem, we introduced two new options and status variables related to the stmt-cache: Options: . binlog_stmt_cache_size . max_binlog_stmt_cache_size Status Variables: . binlog_stmt_cache_use . binlog_stmt_cache_disk_use So there are . binlog_cache_size that defines the size of the transactional cache for updates to transactional engines for the binary log. . binlog_stmt_cache_size that defines the size of the statement cache for updates to non-transactional engines for the binary log. . max_binlog_cache_size that sets the total size of the transactional cache. . max_binlog_stmt_cache_size that sets the total size of the statement cache. . binlog_cache_use that identifies the number of transactions that used the temporary transactional binary log cache. . binlog_cache_disk_use that identifies the number of transactions that used the temporary transactional binary log cache but that exceeded the value of binlog_cache_size. . binlog_stmt_cache_use that identifies the number of statements that used the temporary non-transactional binary log cache. . binlog_stmt_cache_disk_use that identifies the number of statements that used the temporary non-transactional binary log cache but that exceeded the value of binlog_stmt_cache_size.	15 years ago
Luis Soares	06e921818a	BUG#54144: ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE is hard coded The error message for ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded. Additionally, the same error was used in three separate error symptoms: 1. when heartbeat period exceeds the value of slave_net_timeout, 2. when it is smaller than 1 milisecond and 3. when it was not in range, ie, either negative or greater than the maximum allowed. We fix this by splitting into three distinct errors and by removing the message from the source code and moving it to the errmsg-utf8.txt file.	15 years ago
Luis Soares	cc15d2462c	BUG#54144: ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE is hard coded The error message for ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded. Additionally, the same error was used in three separate error symptoms: 1. when heartbeat period exceeds the value of slave_net_timeout, 2. when it is smaller than 1 milisecond and 3. when it was not in range, ie, either negative or greater than the maximum allowed. We fix this by splitting into three distinct errors and by removing the message from the source code and moving it to the errmsg-utf8.txt file.	15 years ago
Davi Arnaut	a5efb91dea	Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table. mysql-test/suite/innodb/t/innodb-truncate.test: Add test cases for truncate and foreign key checks. Also test that InnoDB resets auto-increment on truncate. mysql-test/suite/innodb/t/innodb.test: FK is not necessary, test is related to auto-increment. Update error number, truncate is no longer invoked if table is parent in a FK relationship. mysql-test/suite/innodb/t/innodb_mysql.test: Update error number, truncate is no longer invoked if table is parent in a FK relationship. Use delete instead of truncate, test is used to check the interaction of FKs, triggers and delete. mysql-test/suite/parts/inc/partition_check.inc: Fix typo. mysql-test/suite/sys_vars/t/foreign_key_checks_func.test: Update error number, truncate is no longer invoked if table is parent in a FK relationship. mysql-test/t/mdl_sync.test: Modify test case to reflect and ensure that truncate takes a exclusive metadata lock. mysql-test/t/trigger-trans.test: Update error number, truncate is no longer invoked if table is parent in a FK relationship. sql/ha_partition.cc: Reorganize the various truncate methods. delete_all_rows is now passed directly to the underlying engines, so as truncate. The code responsible for truncating individual partitions is moved to ha_partition::truncate_partition, which is invoked when a ALTER TABLE t1 TRUNCATE PARTITION p statement is executed. Since the partition truncate no longer can be invoked via delete, the bitmap operations are not necessary anymore. The explicit reset of the auto-increment value is also removed as the underlying engines are now responsible for reseting the value. sql/handler.cc: Wire up the handler truncate method. sql/handler.h: Introduce and document the truncate handler method. It assumes certain use cases of delete_all_rows. Add method to retrieve the list of foreign keys referencing a table. Method is used to avoid truncating tables that are parent in a foreign key relationship. sql/share/errmsg-utf8.txt: Add error message for truncate and FK. sql/sql_lex.h: Introduce a flag so that the partition engine can detect when a partition is being truncated. Used to give a special error. sql/sql_parse.cc: Function mysql_truncate_table no longer exists. sql/sql_partition_admin.cc: Implement the TRUNCATE PARTITION statement. sql/sql_truncate.cc: Change the truncate table implementation to use the new truncate handler method and to not rely on row-by-row delete anymore. The truncate handler method is always invoked with a exclusive metadata lock. Also, it is no longer possible to truncate a table that is parent in some non-self-referencing foreign key. storage/archive/ha_archive.cc: Rename method as the description indicates that in the future this could be a truncate operation. storage/blackhole/ha_blackhole.cc: Implement truncate as no operation for the blackhole engine in order to remain compatible with older releases. storage/federated/ha_federated.cc: Introduce truncate method that invokes delete_all_rows. This is required to support partition truncate as this form of truncate does not implement the drop and recreate protocol. storage/heap/ha_heap.cc: Introduce truncate method that invokes delete_all_rows. This is required to support partition truncate as this form of truncate does not implement the drop and recreate protocol. storage/ibmdb2i/ha_ibmdb2i.cc: Introduce truncate method that invokes delete_all_rows. This is required to support partition truncate as this form of truncate does not implement the drop and recreate protocol. storage/innobase/handler/ha_innodb.cc: Rename delete_all_rows to truncate. InnoDB now does truncate under a exclusive metadata lock. Introduce and reorganize methods used to retrieve the list of foreign keys referenced by a or referencing a table. storage/myisammrg/ha_myisammrg.cc: Introduce truncate method that invokes delete_all_rows. This is required in order to remain compatible with earlier releases where truncate would resort to a row-by-row delete.	15 years ago
Davi Arnaut	5f911fa874	Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.	15 years ago
Sergey Vojtovich	37afe1b34a	WL#5341 - Sticky plugins This patch implements "permanent" load option for plugins as specified by WL#5341. mysql-test/r/plugin_load_option.result: A test case for WL#5341. mysql-test/t/plugin_load_option-master.opt: A test case for WL#5341. mysql-test/t/plugin_load_option.test: A test case for WL#5341. sql/share/errmsg-utf8.txt: An error message for WL#5341. sql/sql_plugin.cc: Added FORCE_PLUS_PERMANENT plugin load option. sql/sql_plugin.h: Expose and use plugin load option instead of is_mandatory flag. This is a requirement for to-be-implemented WL5496.	15 years ago
Sergey Vojtovich	42d46376af	WL#5341 - Sticky plugins This patch implements "permanent" load option for plugins as specified by WL#5341.	15 years ago
Mattias Jonsson	86327002fe	Bug#50036: Inconsistent errors when using TIMESTAMP columns/expressions It was hard to understand what the error really meant. The error checking in partitioning is done in several different parts during the execution of a query which can make it hard to return useful errors. Added a new error for bad VALUES part in the per PARTITION clause. Using the more verbose error that a column is not allowed in the partitioning function instead of just that the function is not allowed. mysql-test/r/partition.result: changed error to be more specific mysql-test/r/partition_error.result: updated result mysql-test/std_data/parts/t1TIMESTAMP.frm: .frm file of CREATE TABLE t1 (a TIMESTAMP) PARTITION BY HASH(TO_DAYS(a)); mysql-test/t/partition.test: changed error to be more specific mysql-test/t/partition_error.test: Added test (also for verifying behaviour of previously created tables which is no longer allowed). Updated expected errors in other places sql/partition_info.cc: Added function report_part_expr_error to be able to return a more specific error. Renamed fix_func_partition to fix_partition_values since the function really fixes/checks the VALUES clause. sql/partition_info.h: removed part_result_type, since it was unused. renamed fix_funk_partition->fix_partition_values added report_part_expr_error sql/share/errmsg-utf8.txt: Added a more specific error. sql/sql_partition.cc: made use of report_part_expr_error to get a more specific error. sql/sql_yacc.yy: Changed error message to be more specific. And return an other error code.	15 years ago
Mattias Jonsson	e7dc80b807	Bug#50036: Inconsistent errors when using TIMESTAMP columns/expressions It was hard to understand what the error really meant. The error checking in partitioning is done in several different parts during the execution of a query which can make it hard to return useful errors. Added a new error for bad VALUES part in the per PARTITION clause. Using the more verbose error that a column is not allowed in the partitioning function instead of just that the function is not allowed.	15 years ago
Georgi Kodinov	9705711596	WL#1054: Pluggable authentication support Merged the implementation to a new base tree.	16 years ago

... 2 3 4 5 6

298 Commits (0d107a85b3dd6969e66cc9cb4bd29e1cc92a7d18)