database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Code Activity

fixes after merge. Updates to test's results.

Browse Source 
We now reset the THD members related to auto_increment+binlog in
MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(),
which was not able to distinguish between SELECT myfunc1(),myfunc2()
and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point
of view.
Rows_log_event::exec_event() now calls lex_start() instead of
mysql_init_query() because the latter now does too much (it resets
the binlog format).


mysql-test/extra/rpl_tests/rpl_insert_id.test:
  fix after merge
mysql-test/mysql-test-run.pl:
  -v does not bring useful information when running valgrind; I remove it;
  if you think it's useful add it back.
mysql-test/r/binlog_stm_mix_innodb_myisam.result:
  Position columns of SHOW BINLOG EVENTS are replaced by # (more robust
  if the size of an event changes).
mysql-test/r/rpl_insert_id.result:
  fix after merge
mysql-test/r/rpl_loaddata.result:
  The binlog positions change, because one event disappeared; indeed there
  was this in the binlog (in the current 5.1!):
  SET INSERT_ID=2;
  SET INSERT_ID=1;
  SET TIMESTAMP=1152540671;
  load data LOCAL INFILE '/tmp/SQL_LOAD_MB-1-2' INTO table t1;
  Two INSERT_ID events, useless and a bug. Goes away afer cleaning up
  auto_increment handling.
mysql-test/r/rpl_switch_stm_row_mixed.result:
  INSERT_ID=5 appears, it's a consequence of having merged the fix
  for BUG#20341
  "stored function inserting into one auto_increment puts bad data in slave".
  In mixed mode, if one substatement of a stored procedure requires row-based,
  the entire procedure uses row-based (was already true for stored functions);
  this is a consequence of not doing the resetting of binlog format inside
  lock_tables() (which didn't work with how the slave thread executes
  row-based binlog events).
mysql-test/t/rpl_switch_stm_row_mixed.test:
  removing the multi-row delayed insert because in RBR the number of events
  which it generates, is not repeatable (probably depends on how the delayed
  thread groups rows, i.e. dependent on timing).
sql/ha_partition.cc:
  update to new prototype
sql/ha_partition.h:
  update to new prototype of the handler:: method.
sql/handler.cc:
  after-merge fixes (manually merging part which was hard to merge in fmtool)
sql/log.cc:
  When we write to the binary log, THD's parameters which influenced this
  write are reset: stmt_depends_on_first_successful_insert_id_in_prev_stmt
  and auto_inc_intervals_in_cur_stmt_for_binlog. This is so that future
  writes are not influenced by those and can write their own values.
  As a consequence, when we don't write to the binlog we do not reset.
  This is to abide by the rule that in a complex statement (using triggers etc),
  the first top- or substatement to generate auto_increment ids
  wins their writing to the binlog (that writing may be done by the statement
  itself or by the caller); so for example for
  INSERT INTO t SELECT myfunc() where myfunc() inserts into auto_increment
  and INSERT INTO t does not, myfunc() will fill
  auto_inc_intervals_in_cur_stmt_for_binlog, which will not be reset when
  myfunc() ends, then INSERT INTO t will write to the binlog and thus
  write the preserved auto_inc_intervals_in_cur_stmt_for_binlog.
sql/log_event.cc:
  mysql_init_query() does too much now to be called in Rows_log_event::exec_event
  (it call mysql_reset_thd_for_next_command() which may switch
  the binlog format now).
  It's ok to call it in Table_map_log_event::exec_event() but its call must
  be before setting the binlog format to "row".
sql/sql_base.cc:
  Resetting the binlog format in lock_tables() was a bad idea of mine;
  it causes problems in execution of row-based binlog events, where
  the thread sets the binlog format by itself and does not want a next
  lock_tables() to reset the binlog format.
  It is also misleading, for a function named lock_tables(), to reset
  the binlog format.
  As a consequence of this change, in mixed binlogging mode, a routine
  is logged either entirely statement-based or entirely row-based, we
  don't switch in the middle (this was already true for prelocked routines,
  now it's also true for stored procedures).
sql/sql_class.cc:
  resetting of auto_increment variables used for binlogging is now done
  when writing to the binary log, no need to do the resetting at the end
  of the statement. It is also more correct this way; consider
  SELECT myfunc1(),myfunc2();
  where both functions insert into the same auto_increment column.
  Binlogging is done in 2 events: "SELECT myfunc1()" and "SELECT myfunc2()".
  So each of those needs to have, in binlog, the INSERT_ID which
  it inserted. But as the 2 function calls are executed under prelocked mode,
  the old code didn't reset auto_inc_intervals_in_cur_stmt_for_binlog
  after the first SELECT was binlogged, and so the INSERT_ID of the first
  SELECT was binlogged for the first SELECT and (wrong) also for the 2nd
  SELECT event.
  stmt_depends_on_first_... has the same logic.
sql/sql_class.h:
  clearer comment
sql/sql_delete.cc:
  unneeded #ifdef. As we temporarily change the binlog format to "statement"
  before calling mysql_delete(), we must restore it afterwards.
sql/sql_insert.cc:
  after-merge fixes.
  No need to reset auto_inc_intervals_in_cur_stmt_for_binlog for every
  row in the delayed insert system thread, because we already reset it
  when writing to the binlog.
sql/sql_parse.cc:
  unneeded #ifdef
This commit is contained in:
unknown
2006-07-10 18:41:03 +02:00
parent 3a3a5622ab
commit 20c59f9c4b
18 changed files with 249 additions and 203 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
sql/handler.cc
View File

@@ -1538,6 +1538,58 @@ compute_next_insert_id(ulonglong nr,struct system_variables *variables)
}
void handler::adjust_next_insert_id_after_explicit_value(ulonglong nr)
{
/*
If we have set THD::next_insert_id previously and plan to insert an
explicitely-specified value larger than this, we need to increase
THD::next_insert_id to be greater than the explicit value.
*/
if ((next_insert_id > 0) && (nr >= next_insert_id))
set_next_insert_id(compute_next_insert_id(nr, &table->in_use->variables));
}
/*
Computes the largest number X:
- smaller than or equal to "nr"
- of the form: auto_increment_offset + N * auto_increment_increment
where N>=0.
SYNOPSIS
prev_insert_id
nr Number to "round down"
variables variables struct containing auto_increment_increment and
auto_increment_offset
RETURN
The number X if it exists, "nr" otherwise.
*/
inline ulonglong
prev_insert_id(ulonglong nr, struct system_variables *variables)
{
if (unlikely(nr < variables->auto_increment_offset))
{
/*
There's nothing good we can do here. That is a pathological case, where
the offset is larger than the column's max possible value, i.e. not even
the first sequence value may be inserted. User will receive warning.
*/
DBUG_PRINT("info",("auto_increment: nr: %lu cannot honour "
"auto_increment_offset: %lu",
nr, variables->auto_increment_offset));
return nr;
}
if (variables->auto_increment_increment == 1)
return nr; // optimization of the formula below
nr= (((nr - variables->auto_increment_offset)) /
(ulonglong) variables->auto_increment_increment);
return (nr * (ulonglong) variables->auto_increment_increment +
variables->auto_increment_offset);
}
/*
Update the auto_increment field if necessary
@@ -1643,8 +1695,7 @@ bool handler::update_auto_increment()
the last NULL needs to insert 3764, not the value of the first NULL plus
1).
*/
if ((next_insert_id > 0) && (nr >= next_insert_id))
set_next_insert_id(compute_next_insert_id(nr, variables));
adjust_next_insert_id_after_explicit_value(nr);
insert_id_for_cur_row= 0; // didn't generate anything
DBUG_RETURN(0);
}
@@ -1736,12 +1787,15 @@ bool handler::update_auto_increment()
{
/*
field refused this value (overflow) and truncated it, use the result of
the truncation (which is going to be inserted).
the truncation (which is going to be inserted); however we try to
decrease it to honour auto_increment_* variables.
That will shift the left bound of the reserved interval, we don't
bother shifting the right bound (anyway any other value from this
interval will cause a duplicate key).
*/
nr= table->next_number_field->val_int();
nr= prev_insert_id(table->next_number_field->val_int(), variables);
if (unlikely(table->next_number_field->store((longlong) nr, TRUE)))
nr= table->next_number_field->val_int();
}
if (append)
{