Commit graph

950 commits

Author SHA1 Message Date
Ramil Kalimullin
7f7a1d5455 Auto-merge. 2009-12-17 10:52:43 +04:00
Ramil Kalimullin
092f25caeb Fix for bug#49465: valgrind warnings and incorrect live checksum...
Problem: inserting a record we don't set unused null bits in the
record buffer if no default field values used.
That may lead to wrong live checksum calculation.

Fix: set unused null bits in the record buffer in such cases.
2009-12-17 09:55:03 +04:00
Jon Olav Hauglid
a6733b5277 Bug #47682 strange behaviour of INSERT DELAYED
The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
mode active. The table being inserted into had to be different from the 
table(s) locked by LOCK TABLES.

For INSERT DELAYED, the connection thread waits until the handler thread has
opened and locked its table before returning. But since the global read lock
was active, the handler thread would be unable to lock and would wait for the
global read lock to go away.

So the handler thread would be waiting for the connection thread to release
the global read lock while the connection thread was waiting for the handler
thread to lock the table. This gave a "self-deadlock" (same connection,
different threads).

The deadlock would only happen if we also had LOCK TABLES mode since the
INSERT otherwise will try to get protection against global read lock before
starting the handler thread. It will then notice that the global read lock
is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.

This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
also if we are inside LOCK TABLES mode.

Test case added to delayed.test.
2009-11-18 10:02:21 +01:00
Georgi Kodinov
8f6f3dba21 Bug #40877: multi statement execution fails in 5.1.30
Implemented the server infrastructure for the fix:

1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of 
thd_query()

2. Did some encapsulation in THD : aggregated thd_query and 
thd_query_length into a LEX_STRING and made accessor and mutator 
methods for easy code updating. 

3. Updated the server code to use the new methods where applicable.
2009-10-16 13:29:42 +03:00
Alexander Nozdrin
96c8843514 A patch for Bug#45118 (mysqld.exe crashed in debug mode
on Windows in dbug.c) -- part 2: a patch for the DBUG subsystem
to detect misuse of DBUG_ENTER / DBUG_RETURN macros.
5.1 version.
2009-09-10 11:40:57 +04:00
Satya B
22a97a93b8 merge mysql-5.0-bugteam to mysql-5.1-bugteam 2009-09-04 12:27:10 +05:30
Satya B
eebffb422b Fix for BUG#46384 - mysqld segfault when trying to create table with same
name as existing view

When trying to create a table with the same name as existing view with
join, mysql server crashes.

The problem is when create table is issued with the same name as view, while
verifying with the existing tables, we assume that base table object is 
created always.

In this case, since it is a view over multiple tables, we don't have the 
mysql derived table object.

Fixed the logic which checks if there is an existing table to not to assume
that table object is created when the base table is view over multiple 
tables.
2009-09-04 12:21:54 +05:30
Gleb Shchepa
6aea4cebfc Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!

The problem of that bugreport was mostly fixed by the
patch for bug 38691.
However, attached test case focused on another crash or
valgrind warning problem: SHOW PROCESSLIST query accesses
freed memory of SP instruction that run in a parallel
connection.

Changes of thd->query/thd->query_length in dangerous
places have been guarded with the per-thread
LOCK_thd_data mutex (the THD::LOCK_delete mutex has been
renamed to THD::LOCK_thd_data).
2009-07-24 20:58:58 +05:00
10e90a1fe5 BUG#45574 CREATE IF NOT EXISTS is not binlogged if the object exists
There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and
CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are
binlogged even if either the DB, TABLE or EVENT does not exist. In
contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT
exists.  

This patch fixes the following cases for all the replication formats:
CREATE DATABASE IF NOT EXISTS.
CREATE TABLE IF NOT EXISTS,
CREATE TABLE IF NOT EXISTS ... LIKE,
CREAET TABLE IF NOT EXISTS ... SELECT.
2009-08-13 10:48:57 +08:00
Gleb Shchepa
9c72a7bfea Merge from 5.0
******
manual merge 5.0-bugteam --> 5.1-bugteam (bug 38816)
2009-07-24 21:04:55 +05:00
Sergey Glukhov
c2ed9d36eb 5.0-bugteam->5.1-bugteam merge 2009-07-03 13:39:22 +05:00
Sergey Glukhov
1a539f170d Bug#45806 crash when replacing into a view with a join!
The crash happend because for views which are joins
we have table_list->table == 0 and 
table_list->table->'any method' call leads to crash.
The fix is to perform table_list->table->file->extra()
method for all tables belonging to view.
2009-07-03 13:35:00 +05:00
Martin Hansson
ecd470d190 Merge 2009-06-22 16:01:42 +02:00
Martin Hansson
2cc1134c2c Bug#44653: Server crash noticed when executing random queries with partitions.
When opening a table, it is imperative that the flag
TABLE::auto_increment_field_not_null be false. But if an error occured during
the creation of a table (e.g. the table exists already) with an auto_increment
column and a BEFORE trigger that used the INSERT ... SELECT construct, the
flag was not reset until after error checking. Thus if an error occured,
select_insert::send_data() returned immediately and it was not reset (see * in
pseudocode below).  Crash happened if the table was opened again. Fixed by
resetting the flag after error checking.

nested-loops_join():
  for each row in SELECT table {
    select_insert::send_data():
      if a values is supplied for AUTO_INCREMENT column
         table->auto_increment_field_not_null= TRUE
       else
         table->auto_increment_field_not_null= FALSE
       if (error)
         return 1; *
       if (table->auto_increment_field_not_null == FALSE)
         ...
       table->auto_increment_field_not_null == FALSE 
  }
<-- table returned to table cache and later retrieved by open_table: 
open_table():
  assert(table->auto_increment_field_not_null)
2009-06-22 14:51:33 +02:00
Alfranio Correia
16ead29710 auto-merge mysql-5.1-bugteam (local) --> mysql-5.1-bugteam 2009-06-18 15:16:14 +01:00
Alfranio Correia
ac1b464a33 BUG#43929 binlog corruption when max_binlog_cache_size is exceeded
Large transactions and statements may corrupt the binary log if the size of the
cache, which is set by the max_binlog_cache_size, is not enough to store the
the changes.

In a nutshell, to fix the bug, we save the position of the next character in the
cache before starting processing a statement. If there is a problem, we simply
restore the position thus removing any effect of the statement from the cache.
Unfortunately, to avoid corrupting the binary log, we may end up loosing changes
on non-transactional tables if they do not fit in the cache. In such cases, we
store an Incident_log_event in order to stop the slave and alert users that some
changes were not logged.

Precisely, for every non-transactional changes that do not fit into the cache,
we do the following:
  a) the statement is *not* logged
  b) an incident event is logged after committing/rolling back the transaction,
  if any. Note that if a failure happens before writing the incident event to
  the binary log, the slave will not stop and the master will not have reported
  any error.
  c) its respective statement gives an error

For transactional changes that do not fit into the cache, we do the following:
  a) the statement is *not* logged
  b) its respective statement gives an error

To work properly, this patch requires two additional things. Firstly, callers to
MYSQL_BIN_LOG::write and THD::binlog_query must handle any error returned and
take the appropriate actions such as undoing the effects of a statement. We
already changed some calls in the sql_insert.cc, sql_update.cc and sql_insert.cc
modules but the remaining calls spread all over the code should be handled in
BUG#37148. Secondly, statements must be either classified as DDL or DML because
DDLs that do not get into the cache must generate an incident event since they
cannot be rolled back.
2009-06-18 14:52:46 +01:00
Staale Smedseng
c429fac63c Merge from 5.0-bugteam 2009-06-17 16:56:44 +02:00
Staale Smedseng
30fccdaaae Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
                  
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
2009-06-17 15:54:01 +02:00
Staale Smedseng
e6e1f4ac84 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2

Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
            
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
2009-06-10 16:04:07 +02:00
Tatiana A. Nurnberg
640b7cd6e2 auto-merge 2009-06-05 01:30:08 +02:00
Tatiana A. Nurnberg
b89d2fce58 Bug#32149: Long semaphore wait for adaptive hash latch
Holding on to the temporary inno hash index latch is an optimization in
many cases, but a pessimization in some others.

Release temporary latches for those corner cases we (or rather, or customers,
thanks!) have identified, that is, when we are about to do something that
might take a really long time, like REPAIR or filesort.
2009-06-05 00:23:08 +02:00
He Zhenxing
0793eec018 BUG#41948 Query_log_event constructor needlessly contorted
Make the caller of Query_log_event, Execute_load_log_event
constructors and THD::binlog_query to provide the error code
instead of having the constructors to figure out the error code.
2009-05-30 21:32:28 +08:00
Chad MILLER
128afdc3e5 Merge community up to enterprise, thus ending the community-server
adventure.
2009-05-06 09:06:32 -04:00
Chad MILLER
978e8e06b0 Merge 5.0.80 release and 5.0 community. Version left at 5.0.80. 2009-04-14 13:20:13 -04:00
He Zhenxing
0b9d0592a5 Auto merge 2009-04-08 16:17:26 +08:00
Georgi Kodinov
5bc77b8b61 fixed a compilation warning 2009-03-27 16:25:16 +02:00
He Zhenxing
9530126822 BUG#37145 Killing a statement doing DDL may log binlog event with error code 1053
When the thread executing a DDL was killed after finished its
execution but before writing the binlog event, the error code in
the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED.

This patch fixed the problem by ignoring the kill status when
constructing the event for DDL statements.

This patch also included the following changes in order to
provide the test case.

 1) modified mysqltest to support variable for connection command

 2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
    run mysql client against the slave mysqld.
2009-03-27 13:19:50 +08:00
Georgi Kodinov
7b7d5b5b43 Fixed initialization order warining. 2009-03-24 16:52:35 +02:00
Leonard Zhou
84a63525d5 Merge 2009-03-24 15:29:04 +08:00
Leonard Zhou
56184684f4 Merge 2009-03-24 14:24:27 +08:00
Leonard Zhou
97c6e3f88b BUG#41719 delayed INSERT into timestamp col needs set time_zone for concurrent binlogging
When do 'insert delayed' operation, the time_zone info doesn't be keeped in the row info.
So when we do insert sometime later, time_zone didn't write into binlog.
This will cause wrong result for timestamp column in slave.

Our solution is that adding time_zone info with the delayed-row and
restoring time_zone from row-info when execute that row in the furture by another thread.
So we can write correct time_zone info into binlog and got correct result in slave.
2009-03-24 08:45:05 +08:00
Ignacio Galarza
428e28e00c auto-merge 2009-03-17 16:29:24 -04:00
Davi Arnaut
a2e4449bfc Bug#41098: Query Cache returns wrong result with concurrent insert
The problem is that select queries executed concurrently with
a concurrent insert on a MyISAM table could be cached if the
select started after the query cache invalidation but before
the unlock of tables performed by the concurrent insert. This
race could happen because the concurrent insert was failing
to prevent cache of select queries happening at the same time.

The solution is to add a 'uncacheable' status flag to signal
that a concurrent insert is being performed on the table and
that queries executing at the same time shouldn't cache the
results.
2009-02-19 18:09:35 -03:00
Ignacio Galarza
2d9421c3bb Bug#29125 Windows Server X64: so many compiler warnings
- Remove bothersome warning messages.  This change focuses on the warnings 
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
2009-02-13 11:41:47 -05:00
Ignacio Galarza
2b85c64d65 Bug#29125 Windows Server X64: so many compiler warnings
- Remove bothersome warning messages.  This change focuses on the warnings 
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
2009-02-10 17:47:54 -05:00
Davi Arnaut
bc03c9ef19 Bug#40536: SELECT is blocked by INSERT DELAYED waiting on
upgrading lock, even with low_priority_updates

The problem is that there is no mechanism to control whether a
delayed insert takes a high or low priority lock on a table.

The solution is to modify the delayed insert thread ("handler")
to take into account the global value of low_priority_updates
when taking table locks. The value of low_priority_updates is
retrieved when the insert delayed thread is created and will
remain the same for the duration of the thread.
2009-02-03 15:16:24 -02:00
Chad MILLER
1c73da70ce Merged from 5.0 (enterprise). 2008-12-17 15:01:34 -05:00
timothy.smith@sun.com
abd8574914 Merge from mysql-5.1.30-release 2008-11-27 00:02:10 +01:00
Build Team
366adeab08 Added "Sun Microsystems, Inc." to copyright headers on files modified
since Oct 1st
2008-11-10 21:21:49 +01:00
Georgi Kodinov
e8515f1992 merged 5.0-bugteam -> 5.1-bugteam 2008-10-21 10:55:03 +03:00
Georgi Kodinov
b204dc43cc Bug #38693: leaked memory with blobs!
If delayed insert fails to upgrade the lock it was not
freeing the temporary memory storage used to keep
newly constructed blob values in memory.
Fixed by iterating over the remaining rows in the delayed
insert rowset and freeing the blob storage for each row.

No test suite because it involves concurrent delayed inserts 
on a table and cannot easily be made deterministic. 

Added a correct valgrind suppression for Fedora 9.
2008-10-15 16:55:52 +03:00
Kristofer Pettersson
00b75c2075 automerge 2008-10-15 09:55:15 +02:00
Mats Kindahl
70b18065d0 Bug #34707: Row based replication: slave creates table within wrong database
The failure was caused by executing a CREATE-SELECT statement that creates a
table in another database than the current one. In row-based logging, the
CREATE statement was written to the binary log without the database, hence
creating the table in the wrong database, causing the following inserts to
fail since the table didn't exist in the given database.

Fixed the bug by adding a parameter to store_create_info() that will make
the function print the database name before the table name and used that
in the calls that write the CREATE statement to the binary log. The database
name is only printed if it is different than the currently selected database.

The output of SHOW CREATE TABLE has not changed and is still printed without
the database name.
2008-10-08 11:15:00 +02:00
Kristofer Pettersson
cc9b99a2e1 Bug#38692 concurrent inserts cause valgrind errors in Query_cache::invalidate
Concurrent inserts produce valgrind error messages.
The reason is that the query cache is invalidated after the target table object
is closed.

Since the delayed insert thread already takes care of invalidating the query
cache there is no need to try to synchronize an extra cache invalidation call.

The fix is to remove the query_cache_invalidate3 call altogether.
2008-10-07 11:48:27 +02:00
Narayanan V
83ef8f3427 Bug#38338: REPLACE causes last_insert_id() to return an incorrect value
Fix the write_record function to record auto increment
values in a consistent way.
2008-09-16 18:37:59 +05:30
Kristofer Pettersson
58a4beef17 Auto merge. 2008-09-11 13:23:12 +02:00
Kristofer Pettersson
c01aeb1083 Bug#38692 concurrent inserts cause valgrind errors in Query_cache::invalidate
If a delayed insert thread was aborted by a concurrent 'truncate table'
statement, then the diagnostic area would fail with an assert in a debug build
because no actual error message was pushed on the stack despite a thread
being killed.
      
This patch adds an error message to the stack.
2008-09-10 16:58:03 +02:00
Georgi Kodinov
7f1734eb22 merged 5.1.29-rc into 5.1-bugteam 2008-09-10 12:44:21 +03:00
Ramil Kalimullin
00d7c50e48 Merge 2008-09-05 13:36:02 +05:00
Ramil Kalimullin
ef13c12c0a Fix for bug#38821: Assert table->auto_increment_field_not_null failed
in open_table()

Problem: repeating "CREATE... ( AUTOINCREMENT) ... SELECT" may lead to
an assertion failure.

Fix: reset table->auto_increment_field_not_null after each record 
writing.
2008-09-03 15:17:19 +05:00