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

29396 Commits

Author SHA1 Message Date
b7a4918fe8 merge 5.1 -> 5.5
adjust/modify tests as they were failing if system time zone is set differently.
2011-10-12 10:19:46 +05:30
73db2a1504 bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently. 2011-10-12 10:10:52 +05:30
22fdbd40d4 Test "file_contents" failed in non-community RPMs on SuSE
because the search pattern for the "INFO_*" files was not general enough:
Fixed.
2011-10-10 14:03:29 +02:00
0581820455 manual merge to reconcile with MySQL ticket 27145 2011-10-06 10:55:57 +01:00
2aca5a8d05 merge 5.5-mtr => 5.5 2011-10-05 22:54:16 +02:00
b84202dbc8 merge 5.1-mtr => 5.1 2011-10-05 22:38:00 +02:00
83f3aa148b Silly mistake in gdb output: replaced print with resfile_print,
but the latter only takes one argument, duh!
Fixed by concatenating the args (replace , with .)
2011-10-05 15:16:20 +02:00
dc265dc4a1 Bug #12844282 62075: MTR TESTS SHOULD NOT HAVE TO SAVE & RESET INNODB_FILE_FORMAT_CHECK
This is a redo for 5.5
  Added 'innodb_file_format_max' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server
2011-10-05 15:14:14 +02:00
7141bada7d 5.1 -> 5.5 merge 2011-10-05 13:55:51 +04:00
14dc91ff83 Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT
Problematic query:
insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
When this query is killed in another connection it could lead to crash.
The problem is follwing:
An attempt to obtain table statistics for subselect table in killed query
fails with an error. So JOIN::optimize() for subquery is failed but
it does not prevent further subquery evaluation.
At the first subquery execution JOIN::optimize() is called
(see subselect_single_select_engine::exec()) and fails with
an error. 'executed' flag is set to TRUE and it prevents
further subquery evaluation. At the second call
JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
and in case of uncacheable subquery the 'executed' flag is set
to FALSE before subquery evaluation. So we loose 'optimize stage'
error indication (see subselect_single_select_engine::exec()).
In other words 'executed' flag is used for two purposes, for
error indication at JOIN::optimize() stage and for an
indication of subquery execution. And it seems it's wrong
as the flag could be reset.


mysql-test/r/error_simulation.result:
  test case
mysql-test/t/error_simulation.test:
  test case
sql/item_subselect.cc:
  added new flag subselect_single_select_engine::optimize_error
  which is used for error detection which could happen at optimize
  stage.
sql/item_subselect.h:
  added new flag subselect_single_select_engine::optimize_error
sql/sql_select.cc:
  test case
2011-10-05 13:28:20 +04:00
968e4363fd backporting 11766169, fixing 13034450 2011-10-03 13:41:59 +02:00
996614178b mtr: print which suites are used, unless explicit test names 2011-10-03 13:16:40 +02:00
0122a138e4 BUG#11758262 BUG#13043055:
Fix for commit_1innodb failure on pb2.

Background: as status increment differs for an unsafe statement 
when logged in stmt and row format,  mtr throws a content mismatch
error.

Fix:  call p_verify_status_increment with different arguments
for loging format as stmt and row/mixed and disable query log.
2011-10-03 16:05:52 +05:30
da454e2ee1 bug#bug11747416 post-push fixes to correct file name print out. 2011-09-30 15:58:02 +03:00
0e6afc7f6b BUG#11758262 BUG#13043055
Problem: commit_1innodb fails on pb2 after the patch for BUG#11758262
Background: Certain statements threw warnings only in statement mode causing
the result cintent mismatch.

Fix: disabled warnings from the statements.
2011-09-30 15:16:35 +05:30
0c775ea96f Update the German error message translations (by Stefan Hinz)
and fix some Swedish too.
2011-09-29 15:31:46 +03:00
593c9457cd Bug#11747416 : 32228 A disk full makes binary log corrupt
Binary log of master can get a partially logged event if the server
runs out of disk space and, while waiting for some space to be freed,
is shut down (or crashes). If the server is not stopped, it will just
wait endlessly for space to be freed, thus no partial event anomaly
occurs.  The restarted master server has had a dubious policy to send
the incomplete event to slave which it apparently can't handle.
Although an error was printed out the fact of sending with unclear
error message is a source of confusion.
Actually the problem of presence an incomplete event in the binary log
was already fixed by WL 5493 (which was merged to our current trunk
branch, major version 5.6). The fix makes the server truncate the
binary log on server restart and recovery.

However 5.5 master can't do that. So the current issue is a problem of
sending incomplete events to the slave by 5.5 master.

It is fixed in this patch by changing the policy so that only complete
events are pushed by the dump thread to the IO thread. In addition,
the error text that master sends to the slave when an incomplete event
is found, now states that incomplete event may have been caused by an
out-of-disk space situation and provides coordinates of
the first and the last event bytes read.


mysql-test/std_data/bug11747416_32228_binlog.000001:
  a binlog is added with the last event written partly.
mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result:
  new result file is added.
mysql-test/suite/rpl/r/rpl_log_pos.result:
  results updated.
mysql-test/suite/rpl/r/rpl_manual_change_index_file.result:
  results updated.
mysql-test/suite/rpl/r/rpl_packet.result:
  results updated.
mysql-test/suite/rpl/t/rpl_cant_read_event_incident.test:
  regression test for bug#11747416 : 32228 A disk full makes binary log corrupt
  is added.
sql/share/errmsg-utf8.txt:
  Increasing the explanatory part of ER_MASTER_FATAL_ERROR_READING_BINLOG error message twice
  in order to fit to the updated version which carries some more info.
sql/sql_repl.cc:
  Error text indicating a failure of reading from binlog that master delivers to the slave 
  is made more clear;
  A policy to regard a partial event to send it out to the slave anyway is removed.
2011-09-29 14:14:43 +03:00
5aa1d312a4 mtr --help: add --boot-xxx and sort some debug options 2011-09-29 12:34:44 +02:00
7944320f4e manual merge 2011-09-29 10:56:21 +01:00
8932ae2166 Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows / underlying table's name
1 - If a user had SHOW VIEW and SELECT privileges on a view and
this view was referencing another view, EXPLAIN SELECT on the outer
view (that the user had privileges on) could reveal the structure
of the underlying "inner" view as well as the number of rows in
the underlying tables, even if the user had privileges on none of
these referenced objects.

This happened because we used DEFINER's UID ("SUID") not just for
the view given in EXPLAIN, but also when checking privileges on
the underlying views (where we should use the UID of the EXPLAIN's
INVOKER instead).

We no longer run the EXPLAIN SUID (with DEFINER's privileges).
This prevents a possible exploit and makes permissions more
orthogonal.

2 - EXPLAIN SELECT would reveal a view's structure even if the user
did not have SHOW VIEW privileges for that view, as long as they
had SELECT privilege on the underlying tables.

Instead of requiring both SHOW VIEW privilege on a view and SELECT
privilege on all underlying tables, we were checking for presence
of either of them.

We now explicitly require SHOW VIEW and SELECT privileges on
the view we run EXPLAIN SELECT on, as well as all its
underlying views. We also require SELECT on all relevant
tables. 


mysql-test/r/view_grant.result:
  add extensive tests to illustrate desired behavior and
  prevent regressions (as always).
mysql-test/t/view_grant.test:
  add extensive tests to illustrate desired behavior and
  prevent regressions (as always).
sql/sql_view.cc:
  We no longer run the EXPLAIN SUID (with DEFINER's privileges).
  To achieve this, we use a temporary, SUID-less TABLE_LIST for
  the views while checking privileges.
2011-09-29 10:47:11 +01:00
586c0c0ef6 BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL
Problem: The following statements can cause the slave to go out of sync 
if logged in statement format: 
INSERT IGNORE...SELECT 
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 
REPLACE ... SELECT 
UPDATE IGNORE :
CREATE ... IGNORE SELECT 
CREATE ... REPLACE SELECT  
           
Background: Since the order of the rows returned by the SELECT 
statement or otherwise may differ on master and slave, therefore
the above statements may cuase the salve to go out of sync with
the master. 
      
Fix:
Issue a warning when statements like the above are exectued and 
the bin-logging format is statement. If the logging format is mixed,
use row based logging. Marking a statement as unsafe has been 
done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while
parsing for a token has been done we cannot be sure if the parsing
of the other tokens has been done as well.
      
Six new warning  messages has been added for each unsafe statement. 
      
binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments.


******
BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL 
Problem: The following statements can cause the slave to go out of sync 
if logged in statement format: 
INSERT IGNORE...SELECT 
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 
REPLACE ... SELECT 
UPDATE IGNORE :
CREATE ... IGNORE SELECT 
CREATE ... REPLACE SELECT  
           
Background: Since the order of the rows returned by the SELECT 
statement or otherwise may differ on master and slave, therefore
the above statements may cuase the salve to go out of sync with
the master. 
      
Fix:
Issue a warning when statements like the above are exectued and 
the bin-logging format is statement. If the logging format is mixed,
use row based logging. Marking a statement as unsafe has been 
done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while
parsing for a token has been done we cannot be sure if the parsing
of the other tokens has been done as well.
      
Six new warning  messages has been added for each unsafe statement. 
      
binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments.



mysql-test/extra/rpl_tests/rpl_insert_duplicate.test:
  Test removed: Added the test to rpl.rpl_insert_ignore.test
  
  
  
  ******
  Test removed: the test is redundant as the same is being tested in rpl.rpl_insert_ignore.
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  Warnings disabled for the unsafe statements.
mysql-test/extra/rpl_tests/rpl_insert_ignore.test:
  1. Disabled warnings while  for unsafe statements
  2. As INSERT...IGNORE is an unsafe statement, an insert ignore not changing any rows, 
  will not be logged in the binary log, in the ROW and MIXED modes. It will however be logged
  in STATEMENT mode.
mysql-test/r/commit_1innodb.result:
  updated result file
  
  
  
  ******
  updated result file
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
  Updated result file.
mysql-test/suite/binlog/r/binlog_unsafe.result:
  updated result file
mysql-test/suite/binlog/t/binlog_unsafe.test:
   added tests for the statements marked as unsafe.
mysql-test/suite/rpl/r/rpl_insert_duplicate.result:
  File Removed :Result file of rpl_insert_duplicate, which has been removed.
mysql-test/suite/rpl/r/rpl_insert_ignore.result:
  Added the content of rpl.rpl_insert_duplicate here.
mysql-test/suite/rpl/r/rpl_insert_select.result:
  Result file removed as the corresponding test has beenn removed.
mysql-test/suite/rpl/r/rpl_known_bugs_detection.result:
  Updated result file.
mysql-test/suite/rpl/t/rpl_insert_duplicate.test:
  File Removed: this was a wrapper for rpl.rpl_insert_duplicate.test, which has been removed.
mysql-test/suite/rpl/t/rpl_insert_select.test:
  File Removed: This test became redundant after this fix, This test showed how INSERT IGNORE...SELECT break replication, which has been handled in this fix.
mysql-test/suite/rpl/t/rpl_known_bugs_detection.test:
  Since all the tests are statement based bugs are being tested, having mixed format
  forces the event to be written in row format. When the statement and causes the
  test to fail as certain known bugs do not occur when the even is logged in row format.
sql/share/errmsg-utf8.txt:
  added 6 new Warning messages.
  
  
  
  ******
  added 6 new Warning messages.
sql/sql_lex.cc:
  Added 6 new error Identifier [ER_BINLOG_STMT_UNSAFEE_*]
sql/sql_lex.h:
  Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug.
  
  
  ******
  Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug.
sql/sql_parse.cc:
  added check for specific queries and marked them as unsafe.
  
  
  ******
  added check for specific queries and marked them as unsafe.
2011-09-29 14:47:27 +05:30
8da9950944 Bug #12373393 PB2 SHOULD ALLOW TO CREATE COLLECTIONS AS SUPER SET OF EXISTING COLLECTIONS
Let CMake parse files with a ".in" suffix containing includes
    Added default.release.in to replace default.release
    Explained in README
    New patch: replace 'include' with '#include' to avoid accidental matches
2011-09-29 10:42:23 +02:00
af400ee256 Merge of fix for bug#11758062 from mysql-5.1. 2011-09-28 16:54:15 +05:30
ffd0a785f4 BUG#11758062 - 50206: ER_TOO_BIG_SELECT REFERS TO OUTMODED
SYSTEM VARIABLE NAME SQL_MAX_JOIN_SI 

BACKGROUND:

ER_TOO_BIG_SELECT refers to SQL_MAX_JOIN_SIZE, which is the
old name for MAX_JOIN_SIZE.

FIX:

Support for old name SQL_MAX_JOIN_SIZE is removed in MySQL 5.6
and is renamed as MAX_JOIN_SIZE.So the errmsg.txt 
and mysql.cc files have been updated and the corresponding result
files have also been updated.
2011-09-28 15:39:21 +05:30
236886d754 Bug#11759349 -- Merge of patch from mysql-5.1. 2011-09-27 17:44:31 +05:30
5dbcff9b9c BUG#11759349 - 51655: CREATE TABLE IN MEMORY ENGINE DOESN'T STORE
CREATE_TIME IN INFORMATION_SC

It was impossible to determine MEMORY table creation time,
since it wasn't stored/exposed.

With this patch creation time is saved and it is available via
I_S.TABLES.CREATE_TIME.

Note: it was decided that additional analysis is required before
implementing UPDATE_TIME. Thus this patch doesn't store UPDATE_TIME.
2011-09-27 17:38:51 +05:30
da756ef676 Bug #12844282 62075: MTR TESTS SHOULD NOT HAVE TO SAVE & RESET INNODB_FILE_FORMAT_CHECK
Added 'innodb_file_format_check' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server
  For 5.5, apparently innodb_file_format_max is the one to ignore
2011-09-27 12:56:05 +02:00
9cc0442527 local merge 2011-09-26 14:29:27 +02:00
0b706e54bb Bug#12985030 SIMPLE QUERY WITH DECIMAL NUMBERS LEAKS MEMORY
Re-write the test, to make pushbuild green.
Workaraound for broken pow() function on:
SunOS tyr40 5.10 Generic_127112-05 i86pc i386 i86pc

(dbx) where
current thread: t@1
=>[1] Item_func_pow::val_real(this = 0x238af20) (optimized), at 0xaa8d13 (line ~1980) in "item_func.cc"

(dbx) print pow(1.01, 1.0)
pow(1.01, 1) = 1.01
(dbx) print pow(1.01, 10.0)
pow(1.01, 10) = 1.1046221254112
(dbx) print pow(1.01, 100.0)
pow(1.01, 100) = 2.7048138294215
(dbx) print pow(1.01, 1000.0)
pow(1.01, 1000) = 20959.155637814
(dbx) print pow(1.01, 10000.0)
pow(1.01, 10000) = 1.635828711189e+43
(dbx) print pow(1.01, 100000.0)
pow(1.01, 100000) = Infinity
(dbx) print pow(1.01, 1000000.0)
pow(1.01, 1000000) = Infinity
(dbx) print pow(1.01, 10000000.0)
pow(1.01, 10000000) = Infinity
(dbx) print pow(1.01, 100000000.0)
pow(1.01, 100000000) = Infinity
(dbx) print pow(1.01, 1000000000.0)
pow(1.01, 1000000000) = 0.0
(dbx) print pow(1.01, 10000000000.0)
pow(1.01, 10000000000) = 0.0

(dbx) print value
value = 1.0111111111111
(dbx) print val2
val2 = 8796093022207.0

(dbx) print pow(value, val2)
pow(value, val2) = 0.0

so it seems pow(1.01, y)
returns Infinity for large y, but then starts to return 0.0 for even larger values of y.
2011-09-26 14:21:28 +02:00
9fb56539d0 Fixed test sys_vars.all_vars: innodb_large_prefix no longer missing 2011-09-26 10:47:08 +02:00
abbc47f5c4 merge from 5.5 main 2011-09-26 10:27:54 +02:00
031b52c415 merge from 5.1 main 2011-09-26 10:06:25 +02:00
7450044eb7 merge from 5.5.16 2011-09-21 12:40:41 +02:00
d27d267ee7 Bug 12963823 - Crash in Purge thread under unusual circumstances.
The problem occurred when indexes are added between the time that an
UNDO record is created and the time that the purge thread comes around
and deletes the old secondary index entries.  The purge thread would
hit an assert when trying to build a secondary index entry for
searching.  The problem was that the old value of those fields were not
in the UNDO record since they were not part of an index when the UPDATE
occured. 
A test case was added to innodb-index.test.
2011-09-20 18:17:36 -06:00
265737d141 Bug 12963823 - Crash in Purge thread under unusual circumstances.
The problem occurred when indexes are added between the time that an
UNDO record is created and the time that the purge thread comes around
and deletes the old secondary index entries.  The purge thread would
hit an assert when trying to build a secondary index entry for
searching.  The problem was that the old value of those fields were not
in the UNDO record since they were not part of an index when the UPDATE
occured. 
A test case was added to innodb-index.test.
2011-09-20 18:12:36 -06:00
daafe71a35 merge from 5.5 main 2011-09-20 12:14:35 +02:00
dbcdad7d4a Bug#12985030 SIMPLE QUERY WITH DECIMAL NUMBERS LEAKS MEMORY
mysql-test/r/func_str.result:
  New test cases.
mysql-test/t/func_str.test:
  New test cases.
strings/dtoa.c:
  Increasing the buffer size slightly made some queries pass without leaks.
  Adding Bfree(p51, alloc) fixed the remaining leaks.
2011-09-20 10:59:48 +02:00
fe4f15f02d upmerge 12916194 2011-09-19 16:11:15 +02:00
4d19a19d6e Bug #12934729 MTR: ADD OPTION TO RUN BOOTSTRAP THROUGH DEBUGGER
Added options --boot-gdb etc.
  Extended gdb_arguments() with optional input argument
  Cannot use set args in gdb init file, as run < <input> kills them (?)
2011-09-19 16:08:52 +02:00
4896fc11b7 Bug #12916194 MTR SHOULD CUT OFF ANALYSIS OF SERVER LOG IF THERE IS TOO MUCH
Added simple cut-off w/warning if > one million lines
2011-09-19 16:06:35 +02:00
c388e9c49d Update of auth_rpl test.
For some reason the test authentication plugin accepted connection with arbitrary password. But the intention of the plugin is that password should equal to the authentication string and in the later versions of the server connection fails if password is wrong. So I have updated auth_rpl test to specify the correct password.
2011-09-16 14:35:25 +02:00
cb9e23bb30 Merge. 2011-09-16 16:21:05 +04:00
a33b42146e Merge. 2011-09-16 16:03:08 +04:00
3f9cbd7731 BUG#11761180 - 53646: MYISAMPACK CORRUPTS TABLES WITH
FULLTEXT INDEXES

myisamchk may create incorrect fulltext index for compressed
tables. Incorrect data pointer size was used while creating
fulltext index.

mysql-test/r/myisampack.result:
  A test case for BUG#11761180.
mysql-test/t/myisampack.test:
  A test case for BUG#11761180.
storage/myisam/ft_boolean_search.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/ft_nlq_search.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/mi_check.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/mi_write.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
2011-09-16 15:30:31 +04:00
26e647eee5 merge 2011-09-15 21:32:25 +02:00
ab761db8d5 Bug#12696518: MEMORY LEAKS IN HA_PARTITION (VALGRIND TESTS ON TRUNK)
(also 5.5+ solution for bug#11766879/bug#60106)

The valgrind warning was due to an unused 'new handler_add_index(...)'
which was never freed.

The error handling did not work (fails as in bug#11766879) and
the implementation was not as transparant as it could, therefore I
made it a bit simpler and more transparant to the underlying handlers.

This way it follows the api better and the error handling works and
is also now tested.

Also added a debug test to verify the error handling.

Improved according to Jon Olavs review:
Added class ha_partition_add_index.
Also added base class Sql_alloc to handler_add_index.
Update 3.
2011-09-15 20:49:39 +02:00
1cfcab041a merge into 5.1-sec of bug#11766879. 2011-09-15 19:26:38 +02:00
40761a9a73 Merge from mysql-5.1.59-release 2011-09-15 18:48:54 +02:00
4f7a290e70 Some tests simplified after 12912120 2011-09-15 13:18:12 +02:00
04c402c452 upmerge 12793118,12912120 2011-09-15 13:09:24 +02:00