1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID

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).
This commit is contained in:
kroki/tomash@moonlight.intranet
2006-10-02 14:28:23 +04:00
parent dead2e0f14
commit 5ea8adfae7
14 changed files with 405 additions and 41 deletions

View File

@ -1252,17 +1252,29 @@ public:
ulonglong next_insert_id;
/* Remember last next_insert_id to reset it if something went wrong */
ulonglong prev_insert_id;
/*
The insert_id used for the last statement or set by SET LAST_INSERT_ID=#
or SELECT LAST_INSERT_ID(#). Used for binary log and returned by
LAST_INSERT_ID()
At the beginning of the statement last_insert_id holds the first
generated value of the previous statement. During statement
execution it is updated to the value just generated, but then
restored to the value that was generated first, so for the next
statement it will again be "the first generated value of the
previous statement".
It may also be set with "LAST_INSERT_ID(expr)" or
"@@LAST_INSERT_ID= expr", but the effect of such setting will be
seen only in the next statement.
*/
ulonglong last_insert_id;
/*
Set to the first value that LAST_INSERT_ID() returned for the last
statement. When this is set, last_insert_id_used is set to true.
current_insert_id remembers the first generated value of the
previous statement, and does not change during statement
execution. Its value returned from LAST_INSERT_ID() and
@@LAST_INSERT_ID.
*/
ulonglong current_insert_id;
ulonglong limit_found_rows;
ulonglong options; /* Bitmap of states */
longlong row_count_func; /* For the ROW_COUNT() function */
@ -1325,7 +1337,22 @@ public:
bool last_cuted_field;
bool no_errors, password, is_fatal_error;
bool query_start_used, rand_used, time_zone_used;
bool last_insert_id_used,insert_id_used, clear_next_insert_id;
/*
last_insert_id_used is set when current statement calls
LAST_INSERT_ID() or reads @@LAST_INSERT_ID, so that binary log
LAST_INSERT_ID_EVENT be generated.
*/
bool last_insert_id_used;
/*
insert_id_used is set when current statement updates
THD::last_insert_id, so that binary log INSERT_ID_EVENT be
generated.
*/
bool insert_id_used;
bool clear_next_insert_id;
/* for IS NULL => = last_insert_id() fix in remove_eq_conds() */
bool substitute_null_with_insert_id;
bool in_lock_tables;
@ -1461,15 +1488,6 @@ public:
insert_id_used=1;
substitute_null_with_insert_id= TRUE;
}
inline ulonglong insert_id(void)
{
if (!last_insert_id_used)
{
last_insert_id_used=1;
current_insert_id=last_insert_id;
}
return last_insert_id;
}
inline ulonglong found_rows(void)
{
return limit_found_rows;