1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-10 04:22:00 +03:00
Commit Graph

26109 Commits

Author SHA1 Message Date
23cbd659a0 Automerge. 2009-10-30 18:59:06 +03:00
b67cdaa351 Bug #48131: crash group by with rollup, distinct, filesort,
with temporary tables

There were two problems the test case from this bug was
triggering:

1. JOIN::rollup_init() was supposed to wrap all constant Items
into another object for queries with the WITH ROLLUP modifier
to ensure they are never considered as constants and therefore
are written into temporary tables if the optimizer chooses to
employ them for DISTINCT/GROUP BY handling.

However, JOIN::rollup_init() was called before
make_join_statistics(), so Items corresponding to fields in
const tables could not be handled as intended, which was
causing all kinds of problems later in the query execution. In
particular, create_tmp_table() assumed all constant items
except "hidden" ones to be removed earlier by remove_const()
which led to improperly initialized Field objects for the
temporary table being created. This is what was causing crashes
and valgrind errors in storage engines.

2. Even when the above problem had been fixed, the query from
the test case produced incorrect results due to some
DISTINCT/GROUP BY optimizations being performed by the
optimizer that are inapplicable in the WITH ROLLUP case.

Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
when the WITH ROLLUP modifier is present, and splitting the
const-wrapping part of JOIN::rollup_init() into a separate
method which is now invoked after make_join_statistics() when
the const tables are already known.

mysql-test/r/olap.result:
  Added a test case for bug #48131.
mysql-test/t/olap.test:
  Added a test case for bug #48131.
sql/sql_select.cc:
  1. Disabled inapplicable DISTINCT/GROUP BY optimizations when
  the WITH ROLLUP modifier is present.
  2. Split the const-wrapping part of JOIN::rollup_init() into a
  separate method.
sql/sql_select.h:
  Added rollup_process_const_fields() declaration.
2009-10-30 18:54:53 +03:00
5bba20bb6a merge 2009-10-30 16:13:13 +02:00
9d96cd6dcb Bug #48291 : crash with row() operator,select into @var, and
subquery returning multiple rows

Error handling was missing when handling subqueires in WHERE 
and when assigning a SELECT result to a @variable.
This caused crash(es). 

Fixed by adding error handling code to both the WHERE 
condition evaluation and to assignment to an @variable.
2009-10-30 15:15:43 +02:00
1e7fb59272 merge 2009-10-30 11:56:32 +02:00
851e250953 Bug #48293: crash with procedure analyse, view with > 10 columns,
having clause...

The fix for bug 46184 was not very complete. It was not covering
views using temporary tables and multiple tables in a FROM clause.
Fixed by reverting the fix for 46184 and making a more general
check that is checking at the right execution stage and for all
of the non-supported cases.
Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
Updated the analyse.test and subselect.test accordingly.
2009-10-30 11:40:44 +02:00
d8accf91fb branches/5.1:
Backport c6121 from branches/zip:

  ------------------------------------------------------------------------
  r6121 | sunny | 2009-10-30 01:42:11 +0200 (Fri, 30 Oct 2009) | 7 lines
  Changed paths:
     M /branches/zip/mysql-test/innodb-autoinc.result
  
  branches/zip: This test has been problematic for sometime now. The underlying
  bug is that the data dictionaries get out of sync. In the AUTOINC code we
  try and apply salve to the symptoms. In the past MySQL made some unrelated
  change and the dictionaries stopped getting out of sync and this test started
  to fail. Now, it seems they have reverted that changed and the test is
  passing again. I suspect this is not he last time that this test will change.
  
  ------------------------------------------------------------------------
2009-10-30 09:18:25 +00:00
bba3b76cdb merge 2009-10-30 10:03:18 +02:00
be04d1a479 Bug#48319: Server crashes on "GRANT/REVOKE ... TO CURRENT_USER"
CURRENT_USER() in GRANT ... TO CURRENT_USER() only gave us a definer,
not a full user (i.e., password-element was not initiliazed). Hence
dereferencing the password led to a crash.

Properly initializes definers now, just so there are no misunderstandings.
Also does some magic so IDENTIFIED BY ... works with CURRENT_USER().

mysql-test/r/grant2.result:
  Show GRANT ... TO CURRENT_USER() no longer crashes.
  Show it to work with IDENTIFIED BY to boot.
mysql-test/t/grant2.test:
  Show GRANT ... TO CURRENT_USER() no longer crashes.
  Show it to work with IDENTIFIED BY to boot.
sql/sql_acl.cc:
  Make IDENTIFIED BY ... work with CURRENT_USER()
sql/sql_parse.cc:
  Zero password-part of definer just in case somebody mistakes this for
  a complete LEX_USER!
2009-10-29 22:06:10 -07:00
f20acaf801 branches/5.1: Chnage WARN_LEVEL_ERROR to WARN_LEVEL_WARN
for push_warning_printf() call in innodb.
Fix Bug#47233: Innodb calls push_warning(MYSQL_ERROR::WARN_LEVEL_ERROR)

rb://170 approved by Marko.
2009-10-30 03:18:38 +00:00
d309fc74bc branches/zip: This test has been problematic for sometime now. The underlying
bug is that the data dictionaries get out of sync. In the AUTOINC code we
try and apply salve to the symptoms. In the past MySQL made some unrelated
change and the dictionaries stopped getting out of sync and this test started
to fail. Now, it seems they have reverted that changed and the test is
passing again. I suspect this is not he last time that this test will change.
2009-10-29 23:42:11 +00:00
eaad6119da Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode
If an outer query is broken, a subquery might not even get set up.
EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
of the half-setup info.

We now catch this case and print as much as we have, as it doesn't cost us
anything (doesn't make regular execution slower).

mysql-test/r/explain.result:
  Show that EXPLAIN EXTENDED with subquery and illegal out query doesn't crash.
  Show also that SHOW WARNINGS will render an additional Note in the hope of
  being, well, helpful.
mysql-test/t/explain.test:
  If we have only half a query for EXPLAIN EXTENDED to print (i.e.,
  incomplete subquery info as outer query is illegal), we should
  provide the user with as much info as we easily can if they ask
  for it. What we should not do is crash when they come asking for
  help, that violates etiquette in some countries.
sql/item_subselect.cc:
  If the sub-query's actually set up, print it. Otherwise, elide.
2009-10-29 16:01:54 -07:00
fcf47d52bc branches/zip: Merge r5912:6112 from branches/5.1:
(after this merge the innodb-autoinc test starts to fail, but
I commit anyway because it would be easier to investigate the
failure this way)

  ------------------------------------------------------------------------
  r5952 | calvin | 2009-09-22 19:45:07 +0300 (Tue, 22 Sep 2009) | 7 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1: fix bug#42383: Can't create table 'test.bug39438'
  
  For embedded server, MySQL may pass in full path, which is
  currently disallowed. It is needed to relax the condition by
  accepting full paths in the embedded case.
  
  Approved by: Heikki (on IM)
  ------------------------------------------------------------------------
  r6032 | vasil | 2009-10-01 15:55:49 +0300 (Thu, 01 Oct 2009) | 8 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1:
  
  Fix Bug#38996 Race condition in ANALYZE TABLE
  
  by serializing ANALYZE TABLE inside InnoDB.
  
  Approved by:	Heikki (rb://175)
  
  ------------------------------------------------------------------------
  r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     A /branches/5.1/mysql-test/innodb_bug47777.result
     A /branches/5.1/mysql-test/innodb_bug47777.test
  
  branches/5.1: Fix bug #47777. Treat the Geometry data same as
  Binary BLOB in ha_innobase::store_key_val_for_row(), since the
  Geometry data is stored as Binary BLOB in Innodb.
  
  Review: rb://180 approved by Marko Makela.
  
  
  ------------------------------------------------------------------------
  r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Ignore negative values supplied by the user when calculating the
  next value to store in dict_table_t. Setting autoincrement columns top negative
  values is undefined behavior and this change should bring the behavior of
  InnoDB closer to what users expect. Added several tests to check.
  rb://162
  
  ------------------------------------------------------------------------
  r6052 | sunny | 2009-10-12 07:09:56 +0300 (Mon, 12 Oct 2009) | 4 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Reset the statement level autoinc counter on ROLLBACK. Fix
  the test results too.
  rb://164
  
  ------------------------------------------------------------------------
  r6053 | sunny | 2009-10-12 07:37:49 +0300 (Mon, 12 Oct 2009) | 6 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Copy the maximum AUTOINC value from the old table to the new
  table when MySQL does a CREATE INDEX ON T. This is required because MySQL
  does a table copy, rename and drops the old table.
  Fix Bug#47125: auto_increment start value is ignored if an index is created and engine=innodb
  rb://168
  
  ------------------------------------------------------------------------
  r6076 | vasil | 2009-10-14 19:30:12 +0300 (Wed, 14 Oct 2009) | 4 lines
  Changed paths:
     M /branches/5.1/row/row0mysql.c
  
  branches/5.1:
  
  Fix typo.
  
  ------------------------------------------------------------------------
2009-10-29 16:15:50 +00:00
ac37324843 Bug #42116 : Mysql crash on specific query
Queries with nested outer joins may lead to crashes or 
bad results because an internal data structure is not handled
correctly.
The optimizer uses bitmaps of nested JOINs to determine
if certain table can be placed at a certain place in the
JOIN order.
It does maintain a bitmap describing in which JOINs 
last placed table is nested.
When it puts a table it makes sure the bit of every JOIN that
contains the table in question is set (because JOINs can be nested).
It does that by recursively setting the bit for the next enclosing
JOIN when this is the first table in the JOIN and recursively 
resetting the bit if it's the last table in the JOIN.
When it removes a table from the join order it should do the
opposite : recursively unset the bit if it's the only remaining 
table in this join and and recursively set the bit if it's removing
the last table of a JOIN.
There was an error in how the bits was set for the upper levels :
when removing a table it was setting the bit for all the enclosing 
nested JOINs even if there were more tables left in the current JOIN
(which practically means that the upper nested JOINs were not affected).
Fixed by stopping the recursion at the relevant level.

mysql-test/r/join.result:
  Bug #42116: test case
mysql-test/t/join.test:
  Bug #42116: test case
sql/sql_select.cc:
  Bug #41116: don't go up and set the bits if more tables in
  at the current JOIN level
2009-10-29 17:24:29 +02:00
09668c0124 Bug #46828 rpl_get_master_version_and_clock fails on PB-2
The 'rpl_get_master_version_and_clock' test verifies if the slave I/O 
thread tries to reconnect to master when it tries to get the values of 
the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection. 
So the master server is restarted for making the transient network 
disconnection. Restarting master server can bring two problems as following:

1. The time out error is encountered sporadically. The slave I/O thread tries 
   to reconnect master ten times, which is set in my.cnf. So in the test 
   framework sporadically the slave I/O thread really stoped when it can't 
   reconnect to master in the ten times successfully before the master starts, 
   then the time out error will be encountered while waiting for the slave to 
   start.

2. These warnings and errors are produced in server log file when 
   the slave I/O thread tries to get the values of the UNIX_TIMESTAMP, 
   SERVER_ID from master under the transient network disconnection.

To fix problem 1, increase the master retry count to sixty times, 
so that the slave I/O thread has enough time to reconnect master 
successfully.
To fix problem 2, suppress these warnings and errors by mtr suppression, 
because they are expected.


mysql-test/suite/rpl/t/rpl_get_master_version_and_clock-slave.opt:
  Added the *.opt file for increasing master retry count to 
  sixty times.
mysql-test/suite/rpl/t/rpl_get_master_version_and_clock.test:
  Added mtr suppression for suppressing warnings and errors 
  in server log file.
2009-10-29 10:26:59 +08:00
17ed708975 BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null()
XA START may cause assertion failure/server crash when it is called
after unilateral roll back issued by the Resource Manager (both
in regular transaction and after XA transaction).

The problem was that rm_error variable wasn't set/reset properly.

mysql-test/r/xa.result:
  A test case for BUG#43171.
mysql-test/t/xa.test:
  A test case for BUG#43171.
sql/handler.cc:
  Setting rm_error when we're out of XA transaction has no
  special meaning. But it blocks reset of thd->transaction.xid
  structure later.
sql/sql_parse.cc:
  Reset rm_error before we enter ha_rollback(), so
  thd->transaction.xid strucure is reinitialized.
2009-10-28 19:39:08 +04:00
f130de4fb8 A patch and a test case for
Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.

If a transaction was rolled back inside InnoDB due to a deadlock
or lock wait timeout, and the statement had IGNORE clause,
the server could crash at the end of the statement or on shutdown.

This was caused by the error handling infrastructure's attempt to 
ignore a non-ignorable error.

When a transaction rollback request is raised, switch off 
current_select->no_error flag, so that the following error
won't be ignored.

Instead, we could add !thd->is_fatal_sub_stmt_error to
my_message_sql(), but since in write_record() we switch
off no_error, the same approach is used in 
thd_mark_transaction_to_rollback().

@todo: call thd_mark_transaction_to_rollback() from 
handler::print_error(), then we can easily make sure
that the error reported by print_error is not ignored.

mysql-test/r/innodb_lock_wait_timeout_1.result:
  Update results (Bug#46539).
mysql-test/t/innodb_lock_wait_timeout_1.test:
  Add a test case for Bug#46539
sql/sql_class.cc:
  When a transaction rollback request is raised, switch of 
  current_select->no_error flag, so that the following error
  won't be ignored.
2009-10-28 17:49:56 +03:00
97f4ca3acd 5.0-bugteam->5.1-bugteam merge 2009-10-28 13:23:02 +04:00
0b10509e3b Bug#41049 does syntax "grant" case insensitive?
test result fix

mysql-test/suite/funcs_1/r/is_columns_mysql.result:
  test result fix
mysql-test/suite/funcs_1/r/is_statistics.result:
  test result fix
2009-10-28 13:15:33 +04:00
a382917684 BUG#48297: Schema name is ignored when LOAD DATA is written into
binlog, replication aborts

In SBR or MBR, the schema name is not being written to the binlog
when executing a LOAD DATA statement. This becomes a problem when
the current database (lets call it db1) is different from the
table's schema (lets call it db2). For instance, take the
following statements:
  
  use db1;
  load data local infile 'infile.txt' into table db2.t

Should this statement be logged without t's schema (db2), when
replaying it, one can get db1.t populated instead of db2.t (if
db1.t exists). On the other hand, if there is no db1.t at all,
replication will stop.

We fix this by always logging the table (in load file) with fully
qualified name when its schema is different from the current
database or when no default database was selected.
2009-10-27 15:15:53 +00:00
a5b5db32b4 Merge 5.1-bugteam -> 5.1-bugteam-local. 2009-10-27 18:30:02 +04:00
578007404d A follow-up to fix for
BUG#47073 - valgrind errs, corruption,failed repair of partition,
            low myisam_sort_buffer_size

Fixed race conditions discovered with the provided test case and
stabilized test case.

include/myisam.h:
  Serialize submission of messages from multi-threaded REPAIR.
mysql-test/r/myisam.result:
  REPAIR output highly depend on threads activity. Disabled
  result log to make test case deterministic.
mysql-test/t/myisam.test:
  REPAIR output highly depend on threads activity. Disabled
  result log to make test case deterministic.
storage/myisam/ha_myisam.cc:
  Serialize submission of messages from multi-threaded REPAIR.
storage/myisam/mi_check.c:
  Serialize submission of messages from multi-threaded REPAIR.
storage/myisam/sort.c:
  Only master thread is allowed to detach write cache from
  the share.
2009-10-27 18:27:27 +04:00
313c5a01ee Bug #47930: MATCH IN BOOLEAN MODE returns too many results
inside subquery

Re-setting a fulltext index was a no-operation if not all
the matches of a search were consumed by reading them.
This was preventing a joined table using a fulltext index
in a subquery that requires only 1 row of output (e.g. EXISTS) 
from working correctly because the second execution of the 
sub-query has the fulltext index cursor in a wrong state and
was not finding results.
Fixed by making the re-init code _ftb_init_index_search() 
to re-set open cursors in addition to depleted ones.
2009-10-27 14:43:12 +02:00
bbbad7fee5 merge 2009-11-10 12:59:02 +02:00
0daad80228 merge 2009-11-10 10:58:43 +02:00
3823ac329e automerge 2009-10-27 15:04:59 +04:00
f554a3c094 5.0-bugteam->5.1-bugteam merge 2009-10-27 14:09:36 +04:00
6ceaf234bb auto-merge 2009-10-27 02:53:16 -07:00
f0a7ff8419 Bug#41049 does syntax "grant" case insensitive?
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note: 
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).


mysql-test/include/have_case_insensitive_fs.inc:
  test case
mysql-test/r/case_insensitive_fs.require:
  test case
mysql-test/r/grant_lowercase_fs.result:
  test result
mysql-test/r/lowercase_fs_off.result:
  test result
mysql-test/r/ps_grant.result:
  test result
mysql-test/r/system_mysql_db.result:
  changed Routine_name field collation to case insensitive
mysql-test/t/grant_lowercase_fs.test:
  test case
mysql-test/t/lowercase_fs_off.test:
  test case
scripts/mysql_system_tables.sql:
  changed Routine_name field collation to case insensitive
scripts/mysql_system_tables_fix.sql:
  changed Routine_name field collation to case insensitive
sql/sql_acl.cc:
  Problem 1:
  column_priv_hash uses utf8_general_ci collation
  for the key comparison. The key consists of user name,
  db name and table name. Thus user with privileges on table t1
  is able to perform the same operation on T1
  (the similar situation with user name & db name, see acl_cache).
  So collation which is used for column_priv_hash and acl_cache
  should be case sensitive.
  The fix:
  replace system_charset_info with my_charset_utf8_bin for
  column_priv_hash and acl_cache
  Problem 2:
  The same situation with proc_priv_hash, func_priv_hash,
  the only difference is that Routine name is case insensitive.
  So the fix is to use my_charset_utf8_bin for
  proc_priv_hash & func_priv_hash and convert routine name into lower
  case before writing the element into the hash and
  before looking up the key.
  Additional fix: mysql.procs_priv Routine_name field collation
  is changed to utf8_general_ci.
  It's necessary for REVOKE command
  (to find a field by routine hash element values).
  Note: 
  It's safe for lower-case-table-names mode too because
  db name & table name are converted into lower case
  (see GRANT_NAME::GRANT_NAME).
2009-10-27 12:09:19 +04:00
c22826bfad Bug #48240 "Test suite timeout" and "Too many tests failed" is masked from status page
Prepend "Completed", "Timeout" or "Too many failed" to summary line
2009-10-26 14:28:51 +01:00
fb043f9bc2 rpl_cross_version made experimental because of bug #43913 2009-10-26 14:33:03 +02:00
9a5a77eb68 automerge 2009-10-24 09:57:31 +03:00
1339fb17fe Auto-merge. 2009-10-23 23:37:57 +05:00
c2d3d6bbef automerge 2009-10-23 16:35:06 +02:00
d539c1570b Revert the fix for bug #47627 as it's causing the regression tests in pb2 to
fail.
2009-10-23 16:54:58 +03:00
6354112983 Bug #47919 assert in open_table during ALTER temporary table
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.
2009-10-23 15:09:14 +02:00
88084d6763 merged 5.1-main-> 5.1-bugteam 2009-10-23 15:12:26 +03:00
b7ce2a01bc Fix for bug#48258: Assertion failed when using a spatial index
Problem: involving a spatial index for "non-spatial" queries
(that don't containt MBRXXX() functions) may lead to failed assert.

Fix: don't use spatial indexes in such cases.


mysql-test/r/gis-rtree.result:
  Fix for bug#48258: Assertion failed when using a spatial index
    - test result.
mysql-test/t/gis-rtree.test:
  Fix for bug#48258: Assertion failed when using a spatial index
    - test case.
sql/opt_range.cc:
  Fix for bug#48258: Assertion failed when using a spatial index
    - allow only spatial functions (MBRXXX) for itMBR keyparts.
2009-10-23 16:26:48 +05:00
d2d03e923e Bug #48209 Confusing message "Test has succeeded" after test fails due to warnings
There's no need for --verbose for the mysqltest in check-warnings, remove it
2009-10-23 13:04:55 +02:00
33a22fd9a5 branches/zip: Update test result with the WARN_LEVEL_ERROR
to WARN_LEVEL_WARN change. This is the same result as 
submitted in rb://172 review, which approved by Sunny Bains
and Marko.
2009-10-23 07:45:50 +00:00
3fd3aa4620 BUG#34582: mysql-5.1-bugteam-bug-branch --> mysql-5.1-bugteam-latest
(automerge)
2009-10-23 01:03:41 +01:00
77998869ee Autopush 2009-10-22 14:40:15 +05:00
86e1f6f150 branches/zip: As a request from mysql, WARN_LEVEL_ERROR cannot
be used for push_warning_* call any more. Switch to 
WARN_LEVEL_WARN. Bug #47233.
rb://172 approved by Sunny Bains and Marko.
2009-10-22 02:51:07 +00:00
260e15089b branches/zip: Port bug #46000 related changes from 5.1 to zip
branch. Due to different code path for creating index in zip
branch comparing to 5.1), the index reserved name check function
is extended to be used in ha_innobase::add_index(). 
rb://190  Approved by: Marko
2009-10-22 01:58:39 +00:00
0c2d74c60b BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#47741 to mysql-5.1-bugteam
2009-10-22 01:21:50 +01:00
925ac7f4eb BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam

Post-fix for BUG#43789.
2009-10-22 01:19:52 +01:00
7e5cf52c3e BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
                              
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
                              
To fix the problem, we proceed as follows:
                              
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
                              
2 - However, if it is STRICT mode, then a we do what follows:
                              
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
                              
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
                        
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
                        
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
                        
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
                        
(master)
create table t1 (a int);
create table t2 (a int);
                        
(slave)
create table t1 (a int);
create table t2 (a int not null);
                        
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
                        
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
deea727fce BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#38173 to mysql-5.1-bugteam

The reason of  the bug was incompatibile with the master side behaviour.
INSERT query on the master is allowed to insert into a table without specifying
values of DEFAULT-less fields if sql_mode is not strict.
                  
Fixed with checking sql_mode by the sql thread to decide how to react.
Non-strict sql_mode should allow Write_rows event to complete.
                  
todo: warnings can be shown via show slave status, still this is a 
separate rather general issue how to show warnings for the slave threads.
2009-10-22 01:10:42 +01:00
17ed6b9abd Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index

Problem: "Spatial indexes can be involved in the search 
for queries that use a function such as MBRContains() 
or MBRWithin() in the WHERE clause".
Using spatial indexes for JOINs with =, <=> etc.
predicates is incorrect.

Fix: disable spatial indexes for such queries.


mysql-test/r/select.result:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - test result.
mysql-test/t/select.test:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - test case.
sql/sql_select.cc:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - disable spatial indexes for queries which use 
  non-spatial conditions (e.g. NATURAL JOINs).
2009-10-21 14:04:08 +05:00
19ffe23085 Bug #47780: crash when comparing GIS items from subquery
If the first argument to GeomFromWKB function is a geometry
field then the function just returns its value.
However in doing so it's not preserving first argument's 
null_value flag and this causes unexpected null value to
be returned to the calling function.
      
Fixed by updating the null_value of the GeomFromWKB function
in such cases (and all other cases that return a NULL e.g.
because of not enough memory for the return buffer).
2009-10-21 11:43:45 +03:00