An error occurred fetching the project authors.
- 28 Sep, 2009 1 commit
-
-
Tatiana A. Nurnberg authored
"load data" statements were written to the binlog as a mix of the original statement and bits recreated from parse-info. This relied on implementation details and broke with IGNORE_SPACES and versioned comments. We now completely resynthesize the query for LOAD DATA for binlog (which among other things normalizes them somewhat with regard to case, spaces, etc.). We have already parsed the query properly, so we make use of that rather than mix-and-match string literals and parsed items. This should make us safe with regard to versioned comments, even those spanning multiple tokens. Also no longer affected by IGNORE_SPACES.
-
- 31 Jul, 2009 1 commit
-
-
Gleb Shchepa authored
when used with --tab 1) New syntax: added CHARACTER SET clause to the SELECT ... INTO OUTFILE (to complement the same clause in LOAD DATA INFILE). mysqldump is updated to use this in --tab mode. 2) ESCAPED BY/ENCLOSED BY field parameters are documented as accepting CHAR argument, however SELECT .. INTO OUTFILE silently ignored rests of multisymbol arguments. For the symmetrical behavior with LOAD DATA INFILE the server has been modified to fail with the same error: ERROR 42000: Field separator argument is not what is expected; check the manual 3) Current LOAD DATA INFILE recognizes field/line separators "as is" without converting from client charset to data file charset. So, it is supposed, that input file of LOAD DATA INFILE consists of data in one charset and separators in other charset. For the compatibility with that [buggy] behaviour SELECT INTO OUTFILE implementation has been saved "as is" too, but the new warning message has been added: Non-ASCII separator arguments are not fully supported This message warns on field/line separators that contain non-ASCII symbols.
-
- 17 Jun, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.
-
- 10 Jun, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.
-
- 30 May, 2009 1 commit
-
-
He Zhenxing authored
Make the caller of Query_log_event, Execute_load_log_event constructors and THD::binlog_query to provide the error code instead of having the constructors to figure out the error code.
-
- 21 Feb, 2009 1 commit
-
-
Alfranio Correia authored
If secure-file-priv was set on slave, it became unable to execute LOAD DATA INFILE statements sent from master using mixed or statement-based replication. This patch fixes the issue by ignoring this security restriction and checking if the files are created and read by the slave in the --slave-load-tmpdir while executing the SQL Thread.
-
- 10 Feb, 2009 1 commit
-
-
Ignacio Galarza authored
- Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length
-
- 17 Sep, 2008 1 commit
-
-
Tatiana A. Nurnberg authored
NO_BACKSLASH_ESCAPES was not heeded in LOAD DATA INFILE and SELECT INTO OUTFILE. It is now.
-
- 28 Mar, 2008 1 commit
-
-
anozdrin/alik@quad.opbmk authored
The problem was that LOAD DATA code (sql_load.cc) didn't take into account that there may be items, representing references to other columns. This is a usual case in views. The crash happened because Item_direct_view_ref was casted to Item_user_var_as_out_param, which is not a base class. The fix is to 1) Handle references properly; 2) Ensure that an item is treated as a user variable only when it is a user variable indeed; 3) Report an error if LOAD DATA is used to load data into non-updatable column.
-
- 21 Mar, 2008 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
The bool data type was redefined to BOOL (4 bytes on windows). Removed the #define and fixed some of the warnings that were uncovered by this. Note that the fix also disables 2 warnings : 4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning) 4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation These warnings will be handled in a separate bug, as they are performance related or bogus. Fixed to int the return type of functions that return more than 2 distinct values.
-
- 19 Feb, 2008 2 commits
-
-
kostja@dipika.(none) authored
does not send it to the client.
-
kostja@dipika.(none) authored
a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
-
- 30 Oct, 2007 1 commit
-
-
aelkin/elkin@koti.dsl.inet.fi authored
involved bug#12691, bug#27571
-
- 29 Oct, 2007 1 commit
-
-
aelkin/elkin@koti.dsl.inet.fi authored
Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing.
-
- 21 Aug, 2007 1 commit
-
-
Binlogging of the statement with a side effect like a modified non-trans table did not happen. The artifact involved all binloggable dml queries. Fixed with changing the binlogging conditions all over the code to exploit thd->transaction.stmt.modified_non_trans_table introduced by the patch for bug@27417. Multi-delete case has own specific addressed by another bug@29136. Multi-update case has been addressed by bug#27716 and patch and will need merging.
-
- 30 Jul, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333.
-
- 03 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement encoded the 'r' string to a 4 byte string of value x'725c7272' (sequence of 4 characters: r\rr). The LOAD DATA statement decoded this string to a 1 byte string of value x'0d' (ASCII Carriage Return character) instead of the original 'r' character. The same error also happened with the FIELDS ENCLOSED BY clause followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'. NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE recognises 2-byte input sequences like \n, \t, \r and \Z in addition to documented 2-byte sequences: \0 and \N. This feature should be documented (here backspace character is a default ESCAPED BY character, in the real-life example it may be any ESCAPED BY character). NOTE 2, changed behaviour: Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY' clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters encodes this special character itself by doubling it ('r' --> 'rr'), not by prepending it with an escape character.
-
- 10 May, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
-
- 08 May, 2007 3 commits
-
-
evgen@moonbone.local authored
TIMESTAMP field when no value has been provided. The LOAD DATA sets the current time in the TIMESTAMP field with CURRENT_TIMESTAMP default value when the field is detected as a null. But when the LOAD DATA command loads data from a file that doesn't contain enough data for all fields then the rest of fields are simply set to null without any check. This leads to no value being inserted to such TIMESTAMP field. Now the read_sep_field() and the read_fixed_length() functions set current time to the TIMESTAMP field with CURRENT_TIMESTAMP default value in all cases when a NULL value is loaded to the field.
-
cbell/Chuck@mysql_cab. authored
This patch corrects a bug involving a LOAD DATA INFILE operation on a transactional table. It corrects a problem in the error handler by moving the transactional table check and autocommit_or_rollback operation to the end of the error handler. The problem was an assert was thrown after the operation completed. The assert found a non-sunk event in the transaction cache. The events in the transaction cache were added after commit_or_rollack and thereafter nothing removed them. An additional test case was added to detect this condition.
-
cbell/Chuck@mysql_cab. authored
This patch corrects a bug involving a LOAD DATA INFILE operation on a transactional table. It corrects a problem in the error handler moving the transactional table check and autocommit_or_rollback operation to the end of the error handler. An additional test case was added to detect this condition.
-
- 06 Apr, 2007 1 commit
-
-
evgen@moonbone.local authored
NO_AUTO_VALUE_ON_ZERO mode. The table->auto_increment_field_not_null variable wasn't reset after reading a row which may lead to inserting a wrong value to the auto-increment field to the following row. The table->auto_increment_field_not_null variable is reset now right after a row is being written in the read_fixed_length() and the read_sep_field() functions. Removed wrong setting of the table->auto_increment_field_not_null variable in the read_sep_field() function.
-
- 04 Apr, 2007 2 commits
-
-
mskold/marty@mysql.com/linux.site authored
-
mskold/marty@mysql.com/linux.site authored
In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced subject table didn't see the results of operation which caused invocation of those triggers. In other words AFTER trigger invoked as result of update (or deletion) of particular row saw version of this row before update (or deletion). The problem occured because NDB handler in those cases postponed actual update/delete operations to be able to perform them later as one batch. This fix solves the problem by disabling this optimization for particular operation if subject table has AFTER trigger for this operation defined. To achieve this we introduce two new flags for handler::extra() method: HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH. These are called if there exists AFTER DELETE/UPDATE triggers during a statement that potentially can generate calls to delete_row()/update_row(). This includes multi_delete/multi_update statements as well as insert statements that do delete/update as part of an ON DUPLICATE statement.
-
- 30 Mar, 2007 1 commit
-
-
evgen@sunlight.local authored
NO_AUTO_VALUE_ON_ZERO mode. In the NO_AUTO_VALUE_ON_ZERO mode the table->auto_increment_field_not_null variable is used to indicate that a non-NULL value was specified by the user for an auto_increment column. When an INSERT .. ON DUPLICATE updates the auto_increment field this variable is set to true and stays unchanged for the next insert operation. This makes the next inserted row sometimes wrongly have 0 as the value of the auto_increment field. Now the fill_record() function resets the table->auto_increment_field_not_null variable before filling the record. The table->auto_increment_field_not_null variable is also reset by the open_table() function for a case if we missed some auto_increment_field_not_null handling bug. Now the table->auto_increment_field_not_null is reset at the end of the mysql_load() function. Reset the table->auto_increment_field_not_null variable after each write_row() call in the copy_data_between_tables() function.
-
- 23 Mar, 2007 1 commit
-
-
aelkin/elkin@andrepl.(none) authored
thd->options' OPTION_STATUS_NO_TRANS_UPDATE bit was not restored at the end of SF() invocation, where SF() modified non-ta table. As the result of this artifact it was not possible to detect whether there were any side-effects when top-level query ends. If the top level query table was not modified and the bit is lost there would be no binlogging. Fixed with preserving the bit inside of thd->no_trans_update struct. The struct agregates two bool flags telling whether the current query and the current transaction modified any non-ta table. The flags stmt, all are dropped at the end of the query and the transaction.
-
- 01 Mar, 2007 1 commit
-
-
evgen@moonbone.local authored
When INSERT is done over a view the table being inserted into is checked to be unique among all views tables. But if the view contains self-joined table an error will be thrown even if all tables are used under different aliases. The unique_table() function now also checks tables' aliases when needed.
-
- 28 Feb, 2007 1 commit
-
-
bar@mysql.com authored
This patch fixes problem that LOAD DATA could use different character sets when loading files on master and on slave sides: - Adding replication of thd->variables.collation_database - Adding optional character set clause into LOAD DATA Note, the second way, with explicit CHARACTER SET clause should be the recommended way to load data using an alternative character set. The old way, using "SET @@character_set_database=xxx" should be gradually depricated.
-
- 26 Feb, 2007 1 commit
-
-
gbichot@dl145h.mysql.com authored
to the client only after the binlog write and engine commit. No testcase for this bug, as to reproduce it, we need to "kill -9" mysqld, which we cannot do in the testsuite. But, I tested by hand.
-
- 14 Feb, 2007 1 commit
-
-
msvensson@pilot.mysql.com authored
- Implement --secure-file-priv=<dir> option that limits "load_file", "LOAD DATA" and "SELECT .. INTO OUTFILE" to work with files in specified dir. - Use above option for mysqld in mysql-test-run.pl
-
- 31 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Corrected spelling in copyright text Makefile.am: Don't update the files from BitKeeper Many files: Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header Adjusted year(s) in copyright header Many files: Added GPL copyright text Removed files: Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/xwf
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 07 Dec, 2006 2 commits
-
-
cbell/Chuck@suse.vabb.com authored
Please see worklog for details on files changed.
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 06 Dec, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
The problem is that the GEOMETRY NOT NULL can't automatically set any value as a default one. We always tried to complete LOAD DATA command even if there's not enough data in file. That doesn't work for GEOMETRY NOT NULL. Now Field_*::reset() returns an error sign and it's checked in mysql_load()
-
- 02 Dec, 2006 1 commit
-
-
brian@zim.(none) authored
This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
-
- 06 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
-
- 02 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).
-
- 05 Sep, 2006 1 commit
-
-
guilhem@gbichot3.local authored
In 5.0 we made LOAD DATA INFILE autocommit in all engines, while only NDB wanted that. Users and trainers complained that it affected InnoDB and was a change compared to 4.1 where only NDB autocommitted. To revert to the behaviour of 4.1, we move the autocommit logic out of mysql_load() into ha_ndbcluster::external_lock(). The result is that LOAD DATA INFILE commits all uncommitted changes of NDB if this is an NDB table, its own changes if this is an NDB table, but does not affect other engines. Note: even though there is no "commit the full transaction at end" anymore, LOAD DATA INFILE stays disabled in routines (re-entrency problems per a comment of Pem). Note: ha_ndbcluster::has_transactions() does not give reliable results because it says "yes" even if transactions are disabled in this engine...
-