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

1302 Commits

Author SHA1 Message Date
920d185fd8 Merge 2010-12-29 00:47:05 +01:00
fddb1f1b13 - Added/updated copyright headers
- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"
2010-12-28 19:57:23 +01:00
cd36a6a5d5 Fixed following problems:
--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
  before being populated and it leads to incorrect result

We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:

1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.

2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
   process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.

3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.

Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;

4. Derived tables with subquery where subquery
   is evaluated before table locking(Bug#54475, Bug#52157)

Suggested solution is following:

-Introduce new field LEX::context_analysis_only with the following
 possible flags:
 #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
 #define CONTEXT_ANALYSIS_ONLY_VIEW    2
 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
 context analysis operation
-Item_subselect::const_item() returns
 result depending on LEX::context_analysis_only.
 If context_analysis_only is set then we return
 FALSE that means that subquery is non-const.
 As all subquery types are wrapped by Item_subselect
 it allow as to make subquery non-const when
 it's necessary.
2010-12-14 12:33:03 +03:00
180e74bd49 Bug#27606 GRANT statement should be replicated with DEFINER information
"Grantor" columns' data is lost when replicating mysql.tables_priv.
Slave SQL thread used its default user ''@'' as the grantor of GRANT|REVOKE
statements executing on it.

In this patch, current user is put in query log event for all GRANT and REVOKE
statement, SQL thread uses the user in query log event as grantor.
2010-10-23 20:55:44 +08:00
b766a51f41 WL#5370 Keep forward-compatibility when changing
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.

This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT

- Insert nothing and binlog nothing on master if the existing object
  is a view. It only generates a warning that table already exists.
2010-08-18 12:56:06 +08:00
16a7308825 Bug #53493 : add_to_status does not handle the longlong fields in STATUS_VAR
bytes_received/bytes_sent are ulonglong so they cannot be handled by the 
ulong handling code in add_to_status/add_diff_to_status().

Fixed by adding code to handle these two variables in 
add_to_status()/add_diff_to_status() and making sure they are not a subject
to the ulong handling code.
2010-07-14 11:50:17 +03:00
42eecc539a The following statements support the CURRENT_USER() where a user is needed.
DROP USER 
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
executes the log event, 'CURRENT_USER()' is expand to the user of slave 
SQL thread, but SQL thread's user name always NULL. This breaks the replication.

After this patch, session's user will be written into query log events 
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
2010-07-04 12:02:49 +08:00
93fb8bb235 Bug#53445: Build with -Wall and fix warnings that it generates
Apart strict-aliasing warnings, fix the remaining warnings
generated by GCC 4.4.4 -Wall and -Wextra flags.

One major source of warnings was the in-house function my_bcmp
which (unconventionally) took pointers to unsigned characters
as the byte sequences to be compared. Since my_bcmp and bcmp
are deprecated functions whose only difference with memcmp is
the return value, every use of the function is replaced with
memcmp as the special return value wasn't actually being used
by any caller.

There were also various other warnings, mostly due to type
mismatches, missing return values, missing prototypes, dead
code (unreachable) and ignored return values.
2010-07-02 15:30:47 -03:00
1b504ab0b1 Revert Bug#48321 due to build breakage and failing tests. 2010-06-28 17:59:41 -03:00
899a1d694f The following statements support the CURRENT_USER() where a user is needed.
DROP USER 
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
executes the log event, 'CURRENT_USER()' is expand to the user of slave 
SQL thread, but SQL thread's user name always NULL. This breaks the replication.

After this patch, session's user will be written into query log events 
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
2010-06-27 12:42:06 +08:00
dac59fa9c3 Bug#41660: Sort-index_merge for non-first join table may
require O(#scans) memory

When an index merge operation was restarted, it would
re-allocate the Unique object controlling the duplicate row
ID elimination. Fixed by making the Unique object a member
of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout
the lifetime of this object.
2010-06-24 15:21:23 +02:00
1a101920f3 merge 2010-06-04 17:10:22 +03:00
5321e49da6 Bug #52315: utc_date() crashes when system time > year 2037
Some of the server implementations don't support dates later
than 2038 due to the internal time type being 32 bit.
Added checks so that the server will refuse dates that cannot
be handled by either throwing an error when setting date at 
runtime or by refusing to start or shutting down the server if 
the system date cannot be stored in my_time_t.
2010-06-04 16:21:19 +03:00
44fe4c707b Bug #49756 Rows_examined is always 0 in the slow query log for
update statements
      
Only SELECT statements report any examined rows in the slow
log. Slow UPDATE, DELETE and INSERT statements report 0 rows
examined, unless the statement has a condition including a
SELECT substatement.
      
This patch adds counting of examined rows for the UPDATE and
DELETE statements. An INSERT ... VALUES statement will still 
not report any rows as examined.
2010-05-12 13:19:12 +02:00
b89feb5b28 BUG#39053 - UNISTALL PLUGIN does not allow the storage engine
to cleanup open connections

It was possible to UNINSTALL storage engine plugin when binding
between THD object and storage engine is still active (e.g. in
the middle of transaction).

To avoid unclean deactivation (uninstall) of storage engine plugin
in the middle of transaction, additional storage engine plugin
lock is acquired by thd_set_ha_data().

If ha_data is not null and storage engine plugin was not locked
by thd_set_ha_data() in this connection before, storage engine
plugin gets locked.

If ha_data is null and storage engine plugin was locked by
thd_set_ha_data() in this connection before, storage engine
plugin lock gets released.

If handlerton::close_connection() didn't reset ha_data, server does
it immediately after calling handlerton::close_connection().

Note that this is just a framework fix, storage engines must switch
to thd_set_ha_data() from thd_ha_data() if they want to see fit.
2010-04-14 13:53:59 +04:00
ec210cd09d Bug#48525: trigger changes "Column 'id' cannot be null" behaviour
CHECK_FIELD_IGNORE was treated as CHECK_FIELD_ERROR_FOR_NULL;
UPDATE...SET...NULL on NOT NULL fields behaved differently after
a trigger.

Now distinguishes between IGNORE and ERROR_FOR_NULL and save/restores
check-field options.
2010-03-29 03:32:30 +01:00
51e47e1317 revert 48525 2010-02-22 16:58:56 +00:00
c55ba71ec1 Bug#48525: trigger changes "Column 'id' cannot be null" behaviour
CHECK_FIELD_IGNORE was treated as CHECK_FIELD_ERROR_FOR_NULL;
UPDATE...SET...NULL on NOT NULL fields behaved differently after
a trigger.

Now distinguishes between IGNORE and ERROR_FOR_NULL and save/restores
check-field options.
2010-02-18 17:02:17 +00:00
2a22dc2e01 Bug#49534: multitable IGNORE update with sql_safe_updates
error causes debug assertion

The IGNORE option of the multiple-table UPDATE command was
not intended to suppress errors caused by the
sql_safe_updates mode. This flag will raise an error if the
execution of UPDATE does not use a key for row retrieval,
and should continue do so regardless of the IGNORE option.

However the implementation of IGNORE does not support
exceptions to the rule; it always converts errors to
warnings and cannot be extended. The Internal_error_handler
interface offers the infrastructure to handle individual
errors, making sure that the error raised by
sql_safe_updates is not silenced.

Fixed by implementing an Internal_error_handler and using it
for UPDATE IGNORE commands.
2010-02-10 15:37:34 +01:00
6bf8c119fe Backport Bug#37148 to 5.1 2010-01-24 15:03:23 +08:00
0aa3aee0da BUG#46364 MyISAM transbuffer problems (NTM problem)
It is well-known that due to concurrency issues, a slave can become
inconsistent when a transaction contains updates to both transaction and
non-transactional tables in statement and mixed modes.

In a nutshell, the current code-base tries to preserve causality among the
statements by writing non-transactional statements to the txn-cache which
is flushed upon commit. However, modifications done to non-transactional
tables on behalf of a transaction become immediately visible to other
connections but may not immediately get into the binary log and therefore
consistency may be broken.

In general, it is impossible to automatically detect causality/dependency
among statements by just analyzing the statements sent to the server. This
happen because dependency may be hidden in the application code and it is
necessary to know a priori all the statements processed in the context of
a transaction such as in a procedure. Moreover, even for the few cases that
we could automatically address in the server, the computation effort
required could make the approach infeasible.

So, in this patch we introduce the option
    - "--binlog-direct-non-transactional-updates" that can be used to bypass
    the current behavior in order to write directly to binary log statements
    that change non-transactional tables.
2010-01-20 19:08:16 +00:00
e4344ffa41 Auto-merged. 2009-12-02 16:49:21 +03:00
1db3a684e2 Bug#48508: Crash on prepared statement re-execution.
Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.

The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.
2009-12-01 21:28:45 +03:00
cf7e2e1db4 manual merge of 28141 2009-10-20 11:00:07 -07:00
3f42e4bd24 Bug#28141: Control C on query waiting on lock causes ERROR 1053 (server shutdown)
If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".

Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next  Control-C sends KILL CONNECTION
Next  Control-C aborts client.

As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.

client will give more detailed/consistent feedback on Control-C now.
2009-10-19 21:42:10 -07:00
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
bf0aa2bd34 Bug#47280 - strange results from count(*) with order by multiple
columns without where/group
                     
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
                              
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
                  
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
                  
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
2009-10-14 10:46:50 +02:00
0c522f7453 auto-merge 2009-10-01 15:54:11 +02:00
21586dfb08 WL#4259 - Debug Sync Facility
Backport from 6.0 to 5.1.
Only those sync points are included, which are used in debug_sync.test.

  The Debug Sync Facility allows to place synchronization points
  in the code:
  
  open_tables(...)
  
  DEBUG_SYNC(thd, "after_open_tables");
  
  lock_tables(...)
  
  When activated, a sync point can
  
  - Send a signal and/or
  - Wait for a signal
  
  Nomenclature:
  
  - signal:            A value of a global variable that persists
                       until overwritten by a new signal. The global
                       variable can also be seen as a "signal post"
                       or "flag mast". Then the signal is what is
                       attached to the "signal post" or "flag mast".
  
  - send a signal:     Assign the value (the signal) to the global
                       variable ("set a flag") and broadcast a
                       global condition to wake those waiting for
                       a signal.
  
  - wait for a signal: Loop over waiting for the global condition until
                       the global value matches the wait-for signal.
  
  Please find more information in the top comment in debug_sync.cc
  or in the worklog entry.
2009-09-29 17:38:40 +02:00
99bb6acb62 Bug#46958: Assertion in Diagnostics_area::set_ok_status,
trigger, merge table
            
The problem with break statements is that they have very
local effects. Hence a break statement within the inner loop
of a nested-loops join caused execution to proceed to the
next table even though a serious error occurred. The problem
was fixed by breaking out the inner loop into its own
method. The change empowers all errors to terminate the
execution.
            
The errors that will now halt multi-DELETE execution
altogether are 
  - triggers returning errors
  - handler errors
  - server being killed
2009-09-28 12:48:52 +02:00
242bb2634c Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent table
partial backport of bug43138 fix
2009-09-10 13:49:49 +05:00
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
7a77e3d05a Merge mysql-5.1-innodb_plugin to mysql-5.1. 2009-08-11 18:05:25 +05:00
e642140b18 Bug# 30946: mysqldump silently ignores --default-character-set
when used with --tab

1) New syntax: added CHARACTER SET clause to the
  SELECT ... INTO OUTFILE (to complement the same clause in
  LOAD DATA INFILE).
  mysqldump is updated to use this in --tab mode.

2) ESCAPED BY/ENCLOSED BY field parameters are documented as
   accepting CHAR argument, however SELECT .. INTO OUTFILE
   silently ignored rests of multisymbol arguments.
   For the symmetrical behavior with LOAD DATA INFILE the
   server has been modified to fail with the same error:

     ERROR 42000: Field separator argument is not what is
                  expected; check the manual

3) Current LOAD DATA INFILE recognizes field/line separators
   "as is" without converting from client charset to data
   file charset. So, it is supposed, that input file of
   LOAD DATA INFILE consists of data in one charset and
   separators in other charset. For the compatibility with
   that [buggy] behaviour SELECT INTO OUTFILE implementation
   has been saved "as is" too, but the new warning message
   has been added:

     Non-ASCII separator arguments are not fully supported

   This message warns on field/line separators that contain
   non-ASCII symbols.
2009-07-31 22:14:52 +05:00
9c72a7bfea Merge from 5.0
******
manual merge 5.0-bugteam --> 5.1-bugteam (bug 38816)
2009-07-24 21:04:55 +05:00
e9bf99d0c6 Add a comment for thd->proc_info. 2009-07-22 13:44:19 +04:00
cc541211c8 Merge 5.1-bugteam -> 5.1-innodb_plugin. 2009-07-14 15:06:04 +05:00
31b79618e3 Backport WL#3653 to 5.1 to enable bundled innodb plugin.
Remove custom DLL loader code from innodb plugin code, use 
symbols exported from mysqld.
2009-06-10 10:59:49 +02:00
a561a95e6c Fix for a valgrind warning due to use of a uninitialized
variable. The problem was that THD::connect_utime could be
used without being initialized when the main thread is used
to handle connections (--thread-handling=no-threads).
2009-06-08 19:05:24 -03:00
f3e8609960 Bug#44672: Assertion failed: thd->transaction.xid_state.xid.is_null()
The problem is that when a optimization of read-only transactions
(bypass 2-phase commit) was implemented, it removed the code that
reseted the XID once a transaction wasn't active anymore:

sql/sql_parse.cc:

-  bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt));
-  if (!thd->active_transaction())
-    thd->transaction.xid_state.xid.null();
+  thd->transaction.stmt.reset();

This mostly worked fine as the transaction commit and rollback
functions (in handler.cc) reset the XID once the transaction is
ended. But those functions wouldn't reset the XID in case of
a empty transaction, leading to a assertion when a new starting
a new XA transaction.

The solution is to ensure that the XID state is reset when empty
transactions are ended (by either commit or rollback). This is
achieved by reorganizing the code so that the transaction cleanup
routine is invoked whenever a transaction is ended.
2009-06-05 19:16:54 -03:00
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
a645555432 Bug#44658 Create procedure makes server crash when user does not have ALL privilege
MySQL crashes if a user without proper privileges attempts to create a procedure.

The crash happens because more than one error state is pushed onto the Diagnostic
area. In this particular case the user is denied to implicitly create a new user
account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE.

The new account is needed if the original user account contained a host mask.
A user account with a host mask is a distinct user account in this context.
An alternative would be to first get the most permissive user account which
include the current user connection and then assign privileges to that
account. This behavior change is considered out of scope for this bug patch.

The implicit assignment of privileges when a user creates a stored routine is a
considered to be a feature for user convenience and as such it is not
a critical operation. Any failure to complete this operation is thus considered
non-fatal (an error becomes a warning).

The patch back ports a stack implementation of the internal error handler interface.
This enables the use of multiple error handlers so that it is possible to intercept
and cancel errors thrown by lower layers. This is needed as a error handler already
is used in the call stack emitting the errors which needs to be converted.
2009-05-29 15:37:54 +02:00
9d58239dea Pull 5.1 treatment of community features into 5.0. 2009-05-05 17:03:23 -04:00
978e8e06b0 Merge 5.0.80 release and 5.0 community. Version left at 5.0.80. 2009-04-14 13:20:13 -04:00
6379cc00bb Manual merge. 2009-03-25 23:41:16 +04:00
63821b173d Auto-merge 2009-03-25 21:50:42 +04:00
cf6c7262d0 Fix for bug#35383: binlog playback and replication breaks
due to name_const substitution

Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".

For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.

Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().

Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").
2009-03-25 20:48:10 +04:00
bafe7f60c6 Bug#43748: crash when non-super user tries to kill the replication threads
manual merge. also adds test specific to 5.1+
2009-03-25 17:42:34 +01:00
de8042d007 Bug#43748: crash when non-super user tries to kill the replication threads
Fine-tuning. Broke out comparison into method by
suggestion of Davi. Clarified comments. Reverting
test-case which I find too brittle; proper test
case in 5.1+.
2009-03-25 17:10:27 +01:00
ea31e7f828 Merge 2009-03-19 17:43:01 +03:00