| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
MDEV-8938 Server Crash on Update with joins
Make unique table check after setup_fields of update because unique table can materialize table and we do not need field resolving after materialization.
|
| | |
| |
| |
| | |
Make unique table check after setup_fields of update because unique table can materialize table and we do not need field resolving after materialization.
|
| |\ \
| |/ |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
INCORRECT RESULTS
Issue:
-----
Updating varchar and text fields in the same update
statement can produce incorrect results. When a varchar
field is assigned to the text field and the varchar field
is then set to a different value, the text field's result
contains the varchar field's new value.
SOLUTION:
---------
Currently the blob type does not allocate space for the
string to be stored. Instead it contains a pointer to the
varchar string. So when the varchar field is changed as
part of the update statement, the value contained in the
blob also changes.
The fix would be to actually store the value by allocating
space for the blob's string. We can avoid allocating this
space when the varchar field is not being written into.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This assert checks that the server does not try to send OK to the
client if there has been some error during processing. This is done
to make sure that the error is in fact sent to the client.
The problem was that view errors during processing of WHERE conditions
in UPDATE statements where not detected by the update code. It therefore
tried to send OK to the client, triggering the assert.
The bug was only noticeable in debug builds.
This patch fixes the problem by making sure that the update code
checks for errors during condition processing and acts accordingly.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
join view in sql_safe_updates mode.
This bug was unexpectedly fixed along with bug
number 49534. This patch contains only the test
case.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This assertion would occur if UPDATE was used to update multiple
tables containing an AUTO_INCREMENT column and if the inserted
row had a user-supplied value for that column. The assertion
could then be triggered by the next statement.
The problem was only noticeable on debug builds of the server.
The cause of the problem was that the code for multi update did
not properly reset the TABLE->auto_increment_if_null flag after update.
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered in this case by ALTER TABLE.
This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once a row has been updated.
This bug is similar to Bug#47274, but for multi update rather
than INSERT DELAYED.
Test case added to update.test.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
leads to an assertion failure
Any run-time error in stored function (like recursive function
call or update of table that is already updating by statement
which invoked this stored function etc.) that was used in some
expression of the single-table UPDATE statement caused an
assertion failure.
Multiple-table UPDATE (as well as INSERT and both single- and
multiple-table DELETE) are not affected.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In multi_update::send_data(), the counter of matched rows was not correctly incremented, when during insertion of a new row to a temporay table it had to be converted from HEAP to MyISAM.
This fix changes the logic to increment the counter of matched rows in the following cases:
1. If the error returned from write_row() is zero.
2. If the error returned from write_row() is non-zero, is neither HA_ERR_FOUND_DUPP_KEY nor HA_ERR_FOUND_DUPP_UNIQUE, and a call to create_myisam_from_heap() succeeds.
|
| | | |\
| | | |
| | | |
| | | | |
into moonbone.local:/mnt/gentoo64/work/clean-5.0-opt-mysql
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When the ORDER BY clause gets fixed it's allowed to search in the current
item_list in order to find aliased fields and expressions. This is ok for a
SELECT but wrong for an UPDATE statement. If the ORDER BY clause will
contain a non-existing field which is mentioned in the UPDATE set list
then the server will crash due to using of non-existing (0x0) field.
When an Item_field is getting fixed it's allowed to search item list for
aliased expressions and fields only for selects.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
it doesn't select.
This bug was fixed along with bug #16861: User defined variable can
have a wrong value if a tmp table was used.
There the fix consisted of Item_func_set_user_var overloading the method
Item::save_in_field. Consider the query from the test case:
INSERT INTO foo( bar, baz )
SELECT
bar,
@newBaz := 1 + baz
FROM
foo
WHERE
quux <= 0.1;
Here the assignment expression '@newBaz := 1 + baz' is represented by an
Item_func_set_user_var. Its member method save_in_field, which writes the
value of this assignment into the result field, writes the val_xxx() value,
which is not updated at this point. In the fix introduced by the patch,
the save_in_field method reads the actual variable value instead.
See also comment for
ChangeSet@1.2368.1.3, 2007-01-09 23:24:56+03:00, evgen@moonbone.local +4 -0
and comment for
Item_func_set_user_var::save_in_field (item_func.cc)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This performance degradation for UPDATEs could be observed in the update
statements for which the search key cannot be converted to any valid
value of the type of the search column, like for a the condition
int_fld=99999999999999999999999999, though it can be guaranteed here
that there is no row with such a key value.
|
| | | |\ \
| | | |/
| | | |
| | | | |
into mysql.com:/opt/local/work/mysql-5.0-root
|
| | | | |\ |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
used quick select scan.
|
| | | | |\ \
| | | | |/
| | | |/| |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When setup_fields() function finds field named '*' it expands it to the list
of all table fields. It does so by checking that the first char of
field_name is '*', but it doesn't checks that the '* is the only char.
Due to this, when updating table with a field named like '*name', such field
is wrongly treated as '*' and expanded. This leads to making list of fields
to update being longer than list of the new values. Later, the fill_record()
function crashes by dereferencing null when there is left fields to update,
but no more values.
Added check in the setup_fields() function which ensures that the field
expanding will be done only when '*' is the only char in the field name.
|
| | | |\ \ \
| | | |/ / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
depending on table order
multi_update::send_data() was counting updates, not updated rows. Thus if one
record have several updates it will be counted several times in 'rows matched'
but updated only once.
multi_update::send_data() now counts only unique rows.
|
| | | |\ \ \
| | | |/ / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Date field was declared as not null, thus expression 'datefield is null'
was always false. For SELECT special handling of such cases is used.
There 'datefield is null' converted to 'datefield eq "0000-00-00"'.
In mysql_update() before creation of select added remove_eq_conds() call.
It makes some optimization of conds and in particular performs conversion
from 'is null' to 'eq'.
Also remove_eq_conds() makes some evaluation of conds and if it founds that
conds is always false then update statement is not processed further.
All this allows to perform some update statements process faster due to
optimized conds, and not wasting resources if conds known to be false.
|
| | | |\ \ \
| | | |/ /
| | | | |
| | | | | |
into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0-tmp
|
| | | | | | |
|
| | | |\ \ \
| | | |/ / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
optimization: now can use index to find records to update/delete
when there is no WHERE clause.
|
| | | |\ \ \
| | | |/ / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
thd->allow_sum_func was left 'true' after previous statement thus allowing
sum funcs to be present in conditions.
thd->allow_sum_func should be set to 0 for each query and each prepared
statement reinitialization. This is done in lex_start() and
reset_stmt_for_execute().
|
| | | |\ \ \
| | | |/ /
| | | | |
| | | | | |
into mysql.com:/home/my/mysql-5.0
|
| | | | | | |
|
| | | |\ \ \
| | | |/ /
| | | | |
| | | | | |
into moonbone.local:/work/mysql-5.0-bug-11482
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
disabled if ref is built with a key from the updated table
Problem was in add_not_null_conds() optimization function.
It contains following code:
JOIN_TAB *referred_tab= not_null_item->field->table->reginfo.join_tab;
...
add_cond_and_fix(&referred_tab->select_cond, notnull);
For UPDATE described in bug report referred_tab is 0 and dereferencing it
crashes the server.
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
display sizes.
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width.
- Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't produce data truncation warnings from within cp_buffer_from_ref(). This function
is only used to make index search tuples and data truncation that occurs here has no
relation with truncated values being saved into tables.
|
| | | |\ \
| | | |/ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Fix crash with LAST_INSERT_ID() in UPDATE,
Tests included,
|
| | | | | |
|
| | | |\ \
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | | |
Noteworthy:
- New HANDLER code
- New multi-update-grant-check code
- Table lock code in ha_innodb.cc was not applied
|
| | | | |
| | | |
| | | |
| | | | |
We don't want the update to abort when IGNORE is specified
|
| | | |\ \
| | | |/ |
|
| | | | |
| | | |
| | | |
| | | | |
a fix for a test with latest change
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Deprecate the use of TYPE=... Preferred syntax is ENGINE=
|
| | | |\ \
| | | |/ |
|
