GitLab

The auto-inc unsafe warning makes sense even though it's just
one auto-inc table could be involved via a trigger or a stored
function.
However its content was not updated by bug@45677 fixes continuing to mention
two tables whereas the fixes refined semantics of replication of auto_increment 
in stored routine.

Fixed with updating the error message, renaming the error and an internal unsafe-condition 
constants.

A documentation notice
======================

      Inserting into an autoincrement column in a stored function or a trigger
      is unsafe for replication.
      Even with just one autoincrement column, if the routine is invoked more than 
      once slave is not guaranteed to execute the statement graph same way as 
      the master.
      And since it's impossible to estimate how many times a routine can be invoked at 
      the query pre-execution phase (see lock_tables), the statement is marked
      pessimistically unsafe. 



mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  results updated to include the expected unsafe warning.
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
  regression test for bug#50192 to diplaying the unsafe warning comes out to the user warning stack.
sql/share/errmsg-utf8.txt:
  Updating the auto-inc unsafe message to correspond to bug@45677 fixes' new sematics.
sql/share/errmsg.txt:
  Updating the auto-inc unsafe message to correspond to bug@45677 fixes' new sematics.
sql/sql_base.cc:
  changing a symbolic name to correspond to updated by bug@45677 fixes new sematics.
sql/sql_lex.cc:
  changing a symbolic name to correspond to updated by bug@45677 fixes new sematics.
sql/sql_lex.h:
  changing a symbolic name to correspond to updated by bug@45677 fixes new sematics
  and description comments.

sql/sql_base.cc:
  Query_arena *arena and backup are both unused.
  Removing those, allows us to remove select_lex->conds_processed_with_permanent_arena
sql/sql_lex.cc:
  conds_processed_with_permanent_arena is unused
sql/sql_lex.h:
  conds_processed_with_permanent_arena was unused

Non-transactional updates that take place inside a transaction present problems
for logging because they are visible to other clients before the transaction
is committed, and they are not rolled back even if the transaction is rolled
back. It is not always possible to log correctly in statement format when both
transactional and non-transactional tables are used in the same transaction.

In the current patch, we ensure that such scenario is completely safe under the
ROW and MIXED modes.

Backport for 5.5

The root cause of this bug is that the grammar for GROUP BY clauses,
when using WITH CUBE or WITH ROLLUP, cause conflicts with the grammar
for VIEW, when using WITH CHECK OPTION.

The solution is to implement two token look ahead when parsing a WITH token,
to disambiguate the non standard WITH CUBE and WITH ROLLUP syntaxes.

Patch based on code from Marc Alff and Antony Curtis

2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.

This patch implements: 

WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).

WL#4435: Support OUT-parameters in prepared statements.

(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).

Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.

After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.

When using the binary protocol, send the parameters in an additional result
set over the wire.  When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.

The following refactoring has been made:
  - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
  - A new Protocol::send_result_set_row() was introduced to incapsulate
    common functionality for sending row data.
  - Signature of Protocol::prepare_for_send() was changed: this operation
    does not need a list of items, the number of items is fully sufficient.

The following backward incompatible changes have been made:
  - CLIENT_MULTI_RESULTS is now enabled by default in the client;
  - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.

include/mysql.h:
  Add a new flag to MYSQL_METHODS::flush_use_result
  function pointer. This flag determines if all results
  should be flushed or only the first one:
      
  - if flush_all_results is TRUE, then cli_flush_use_result()
    will read/flush all pending results. I.e. it will read
    all packets while server status attribute indicates that
    there are more results. This is a new semantic, required
    to fix the bug.
              
  - if flush_all_results is FALSE, the old sematic
    is preserved -- i.e. cli_flush_use_result() reads data
    until first EOF-packet.
include/mysql.h.pp:
  Update the ABI with new calls (compatible changes).
include/mysql_com.h:
  Add CLIENT_PS_OUT_PARAMS -- a client capability indicating that the client supportsю
libmysql/libmysql.c:
  Add mysql_stmt_next_result() -- analogue of mysql_next_result() for binary protocol.
  Fix a minor bug in alloc_fields() -- not all members were copied over,
  and some only shallow-copied (catalog).
  Flush all results in mysql_stmt_close() (Bug#39519).
libmysqld/lib_sql.cc:
  Rename send_fields() -> send_result_set_metadata().
  Refactoring: change prepare_for_send() so that it accepts only 
  what it really needs -- a number of elements in the list.
mysql-test/r/ps.result:
  Update results: WL#4435.
mysql-test/t/ps.test:
  WL#4435: A test case for an SQL-part of the problem.
sql-common/client.c:
  Bug#39519.
  Implement new functionality in cli_flush_use_result():
  if flush_all_delete is TRUE, then it should read/flush
  all pending results.
sql/Makefile.am:
  Add a new header sql_prepare.h to the list
  of build headers.
sql/events.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/mysql_priv.h:
  Move sql_prepare.cc-specific declarations to a new
  header - sql_prepare.h.
sql/procedure.h:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/protocol.cc:
  Move the logic responsible for sending of one result
  set row to the Protocol class. Define a template
  for end-of-statement action. 
  Refactoring: change prepare_for_send() so that it accepts 
  only what it really needs -- a number of elements in the list.
  Rename send_fields() to send_result_set_metadata().
sql/protocol.h:
  Update with new declarations (WL#4435).
  Rename send_fields() -> send_result_set_metadata().
  prepare_for_send() only needs the number of columns to send,
  and doesn't use the item list - update signature to require
  only what's needed.
  Add a new protocol type -- Protocol_local.
sql/repl_failsafe.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/slave.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_acl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_base.cc:
  Include sql_prepare.h (for Reprepare_observer).
sql/sql_cache.cc:
  Extend the query cache flags block to be able
  to store a numeric id for the result format,
  not just a flag binary/non-binary.
sql/sql_class.cc:
  Update to use the rename of Protocol::send_fields()
  to Protocol::send_result_set_metadata().
  Use Protocol::send_one_result_set_row().
sql/sql_class.h:
  Move the declaration of Reprepare_observer to the 
  new header - sql_prepare.h.
  Update to the new signature of class Protocol::send_fields().
sql/sql_connect.cc:
  Use a protocol template method instead of
  raw NET layer API at the end of a statement.
sql/sql_cursor.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_error.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
  Use new method Protocol::send_one_result_set_row().
sql/sql_help.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_lex.cc:
  Initialize multi_statements variable.
  Add a handy constant for empty lex
  string.
sql/sql_lex.h:
  Add a separate member for a standalone
  parsing option - multi-statements support.
sql/sql_list.cc:
  sql_list.h is a standalone header now, 
  no need to include mysql_priv.h.
sql/sql_list.h:
  Make sql_list.h a stand-alone header.
sql/sql_parse.cc:
  Include sql_prepare.h for prepared
  statements- related declarations.
  Use a new Protocol template method to end
  each statement (send OK, EOF or ERROR to
  the client).
sql/sql_prepare.cc:
  Implement Execute Direct API (WL#4264), 
  currently unused. It will be used by the service
  interface (Backup).
  Use a new header - sql_prepare.h.
  Add support for OUT parameters in the 
  binary and text protocol (prepared statements 
  only).
sql/sql_prepare.h:
  Add a new header to contain (for now)
  all prepared statement- external
  related declarations.
sql/sql_profile.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_repl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_select.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_show.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_string.h:
  Add a way to convert a String to LEX_STRING.
sql/sql_table.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_update.cc:
  Remove an extraneous my_error(). The error
  is already reported in update_non_unique_table_error().
sql/sql_yacc.yy:
  Support for multi-statements is an independent
  property of parsing, not derived from 
  the protocol type.
tests/mysql_client_test.c:
  Add tests for WL#4435 (binary protocol).

----------------------------------------------------------
revno: 2617.22.5
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Tue 2009-01-27 05:08:48 +0300
message:
  Remove non-prefixed use of HASH.
  Always use my_hash_init(), my_hash_inited(), my_hash_search(),
  my_hash_element(), my_hash_delete(), my_hash_free() rather
  than non-prefixed counterparts (hash_init(), etc).
  Remove the backward-compatible defines.

Post-push fix.
Problem: After the original bugfix, if a statement is unsafe,
binlog_format=mixed, and engine is statement-only, a warning was
generated and the statement executed. However, it is a fundamental
principle of binlogging that binlog_format=mixed should guarantee
correct logging, no compromise. So correct behavior is to generate
an error and don't execute the statement.
Fix: Generate error instead of warning.
Since issue_unsafe_warnings can only generate one error message,
this allows us to simplify the code a bit too:
decide_logging_format does not have to save the error code for
issue_unsafe_warnings


mysql-test/suite/binlog/r/binlog_statement_insert_delayed.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_ps.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  updated result file
mysql-test/suite/binlog/r/binlog_unsafe.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_found_rows.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  updated result file
mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result:
  updated result file
mysql-test/suite/rpl_ndb/t/rpl_ndb_binlog_format_errors.test:
  updated test:
   - ER_BINLOG_UNSAFE_AND_STMT_ENGINE is now an error.
   - added test for multiple types of unsafety
sql/share/errmsg.txt:
   - Reformulated ER_BINLOG_UNSAFE_AND_STMT_ENGINE to reflect that it
     is now an error, not a warning.
   - Added "Reason for unsafeness" to ER_BINLOG_UNSAFE_STATEMENT and
     ER_BINLOG_UNSAFE_AND_STMT_ENGINE.
sql/sql_class.cc:
  In decide_logging_format:
   - generate an error immediately in case 3, instead of scheduling a
     warning to be generated later. also updated comments accordingly
   - in case 7, there is only one unsafe warning error code now, so we
     don't need to store it in binlog_unsafe_warning_flags
     (see changes in sql_lex.h)
   - fixed compilation warning in DBUG_PRINT
  
  In issue_binlog_warning:
   - moved array of error codes to sql_lex.h (so that they are
     accessible also from decide_logging_format)
   - simplified code after the first set of bits in
     binlog_unsafe_warning_flags was removed
sql/sql_class.h:
   - got rid of enum_binlog_stmt_warning. It's not needed anymore
     since we only have one type of unsafe warning (one of them
     turned into an error)
   - updated comments accordingly
sql/sql_lex.cc:
  added initialization of the array of error codes that has been
  moved from THD::issue_unsafe_warnings to LEX.
sql/sql_lex.h:
  Moved array of error codes from THD::issue_unsafe_warnings to LEX.

----------------------------------------------------------
revno: 2630.22.8
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Sun 2008-08-10 18:49:52 +0400
message:
  Get rid of typedef struct for the most commonly used types:
  TABLE, TABLE_SHARE, LEX. This simplifies use of tags
  and forward declarations.

storing and restoring information about foreign keys in the .FRM files and
properly displaying it in SHOW CREATE TABLE output and I_S tables.

The idea of this patch is to change type of Key_part_spec::field_name and
Key::name to LEX_STRING in order to avoid extra strlen() calls during
semantic analysis and statement execution, particularly, in code to be
implemented on the 2nd milestone of WL#148.

Note that since we are not using LEX_STRING everywhere yet (e.g. in
Create_field and KEY) and we want to limit scope of our changes we
have to do strlen() in places where we create Key and Key_part_spec
instances from objects using plain (char*) for strings. These calls
will go away during the process of further (char*) -> LEX_STRING
refactoring.

We have introduced these changes in 6.0 and backported them to 5.5
tree to make people aware of these changes as early as possible and
to simplify merges with mysql-fk and mysql-6.1-fk trees.

No test case is needed since this patch does not introduce any
user visible changes.

sql/sql_class.cc:
  Key_part_spec::field_name is now LEX_STRING. Adjusted code accordingly.
sql/sql_class.h:
  Changed type of Key_part_spec::field_name and Key::name to LEX_STRING in
  order to avoid extra strlen() calls in code responsible for semantic
  analysis and statement execution (e.g. in future code responsible for
  saving/restoring info about foreign keys).
sql/sql_lex.cc:
  Moved null_lex_str from sql_yacc.yy to sql_lex.cc and added its
  declaration to sql_lex.h to make it accessible in other SQL-layer
  modules (e.g. sql_parse.cc).
sql/sql_lex.h:
  Made null_lex_str accessible from outside of sql_lex.cc.
sql/sql_parse.cc:
  Key_part_spec::field_name and Key::name are now LEX_STRING. Adjusted
  code accordingly.
sql/sql_table.cc:
  Adjusted code to accomodate change of type to LEX_STRING for
  Key_part_spec::field_name and Key::name.
sql/sql_yacc.yy:
  Now Key::name and Key_part_spec::field_name are LEX_STRINGs. Adjusted
  grammar to be able properly initialize them. This should allow us to
  save on some strlen() calls during later stages of statement execution.

Changed all no_ to num_ to avoid strange names like no_list_values which is not expected to be number of list values, rather a boolea indicating no list values

with gcc 4.3.2
      
This is the fifth patch cleaning up more GCC warnings about
variables used before initialized using the new macro
UNINIT_VAR().

WL#3352, Introducing Column list partitioning, makes it possible to partition on most data types, makes it possible to prune on multi-field partitioning

The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).

The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.

mysql-test/r/ctype_recoding.result:
  Update test case result: ending backtick is not skipped over anymore.
sql/sql_lex.cc:
  Characters being analyzed must be unsigned as they can be
  used as indexes for the parser maps. Only skip over if the
  string is a valid multi-byte sequence.
tests/mysql_client_test.c:
  Add test case for Bug#45010

> ------------------------------------------------------------
> revno: 2852.2.3
> revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l
> parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu
> parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43230-5.1
> timestamp: Fri 2009-04-03 16:46:00 -0300
> message:
>   Merge Bug#43230 into mysql-5.1-bugteam
>     ------------------------------------------------------------
>     revno: 1810.3855.16
>     revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
>     parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg
>     committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
>     branch nick: 43230-5.0
>     timestamp: Fri 2009-04-03 16:11:54 -0300
>     message:
>       Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
>       
>       The problem is that a SELECT .. FOR UPDATE statement might open
>       a table and later wait for a impeding global read lock without
>       noticing whether it is holding a table that is being waited upon
>       the the flush phase of the process that took the global read
>       lock.
>       
>       The same problem also affected the following statements:
>       
>       LOCK TABLES .. WRITE
>       UPDATE .. SET (update and multi-table update)
>       TRUNCATE TABLE ..
>       LOAD DATA ..
>       
>       The solution is to make the above statements wait for a impending
>       global read lock before opening the tables. If there is no
>       impending global read lock, the statement raises a temporary
>       protection against global read locks and progresses smoothly
>       towards completion.
>       
>       Important notice: the patch does not try to address all possible
>       cases, only those which are common and can be fixed unintrusively
>       enough for 5.0.

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.

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.

      
Added a more detailed error message on calling an ambiguous missing function.

mysql-test/r/ps.result:
  Bug #38159: fixed existing tests
mysql-test/r/sp-error.result:
  Bug #38159: test case
mysql-test/t/ps.test:
  Bug #38159: fixed existing tests
mysql-test/t/sp-error.test:
  Bug #38159: test case
sql/item_func.cc:
  Bug #38159: generate more detailed error message
sql/share/errmsg.txt:
  Bug #38159: add a more detailed error message
sql/sql_derived.cc:
  Bug #38159: treat the detailed error message the same way as the
  generic one
sql/sql_lex.cc:
  Bug #38159: 
    - detect if the token is ambiguous and print the appropriate error.
    - backport is_lex_native_function() from 5.1
sql/sql_lex.h:
  Bug #38159: detect if the token is ambiguous and print the appropriate error.
sql/sql_yacc.yy:
  Bug #38159: generate more detailed error message
sql/table.cc:
  Bug #38159: treat the detailed error message the same way as the
  generic one

	comment can't be read back

A change to the lexer in 5.1 caused slash-asterisk-bang-version
sections to be terminated early if there exists a slash-asterisk-
style comment inside it.  Nesting comments is usually illegal,
but we rely on versioned comment blocks in mysqldump, and the
contents of those sections must be allowed to have comments.

The problem was that when encountering open-comment tokens and
consuming -or- passing through the contents, the "in_comment"
state at the end was clobbered with the not-in-a-comment value,
regardless of whether we were in a comment before this or not.  

So, """/*!VER one /* two */ three */""" would lose its in-comment
state between "two" and "three".  Save the echo and in-comment
state, and restore it at the end of the comment if we consume a 
comment.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.

mysql-test/r/lock_multi.result:
  Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
  Add test case for Bug#43230
sql/sql_lex.cc:
  Initialize flag.
sql/sql_lex.h:
  Add a flag to the lexer.
sql/sql_parse.cc:
  Wait for the global read lock is a write lock is going to be
  taken. The wait is done before opening tables.
sql/sql_yacc.yy:
  Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
  .. WRITE statement.

An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE.

During parsing, a global structure is reused for sub-SELECTs and the attribute
keeping track of lock options were not reset properly.
This patch introduces a new attribute to keep track on the syntactical lock
option elements found in a sub-SELECT and then sets the lock options accordingly.

Now the sub-SELECTs will try to acquire a READ lock if possible
instead of a WRITE lock as inherited from the outer DELETE statement.


mysql-test/r/lock.result:
  Added test case for bug39843
mysql-test/t/lock.test:
  Added test case for bug39843
sql/sql_lex.cc:
  * Reset member variable lock_option on each new query.
sql/sql_lex.h:
  * Introduced new member variable 'lock_option' which is keeping track
    of the syntactical lock option of a (sub-)select query.
sql/sql_parse.cc:
  * Wrote comments to functions.
sql/sql_yacc.yy:
  * Introduced an attribute to keep track of syntactical lock options
    in sub-selects.
  * Made sure that the default value TL_READ_DEFAULT is at the begining
    of each subselect-rule.

- 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

Related to operator precedence and associativity.
Make the expressions as explicit as possible.

sql/field.h:
  Silence gcc-4.3 warning: be more explicit.
sql/item.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/item_sum.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/log_event.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/spatial.h:
  Silence gcc-4.3 warning: be more explicit.
sql/sql_lex.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/table.h:
  Silence gcc-4.3 warning: be more explicit.
storage/federated/ha_federated.cc:
  Fix operator precedence bug.
storage/heap/ha_heap.cc:
  Silence gcc-4.3 warning: be more explicit.

since Oct 1st

The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.

The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.

mysql-test/r/limit.result:
  Add test case result for Bug#37075
mysql-test/t/limit.test:
  Add test case for Bug#37075
sql/sql_lex.cc:
  Check for truncation of the offset value. If value was
  truncated, set to the maximum possible value.

          ``FLUSH TABLES WITH READ LOCK''

Concurrent execution of 1) multitable update with a
NATURAL/USING join and 2) a such query as "FLUSH TABLES
WITH READ LOCK" or "ALTER TABLE" of updating table led
to a server crash.


The mysql_multi_update_prepare() function call is optimized
to lock updating tables only, so it postpones locking to
the last, and if locking fails, it does cleanup of modified
syntax structures and repeats a query analysis.  However,
that cleanup procedure was incomplete for NATURAL/USING join
syntax data: 1) some Field_item items pointed into freed
table structures, and 2) the TABLE_LIST::join_columns fields
was not reset.

Major change:
  short-living Field *Natural_join_column::table_field has
  been replaced with long-living Item*.


mysql-test/r/lock_multi.result:
  Added test case for bug #38691.
mysql-test/t/lock_multi.test:
  Added test case for bug #38691.
sql/item.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  The Item_field constructor has been modified to allocate
  and copy original database/table/field names always (not
  during PS preparation/1st execution only), because
  an initialization of Item_field items with a pointer to
  short-living Field structures is a common practice.
sql/sql_base.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  1) Type adjustment for Natural_join_column::table_field
     (Field to Item_field);
  2) The setup_natural_join_row_types function has been
     updated to take into account new
     first_natural_join_processing flag to skip unnecessary
     reinitialization of Natural_join_column::join_columns
     during table reopening after lock_tables() failure
     (like the 'first_execution' flag for PS).
sql/sql_lex.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Initialization of the new
  st_select_lex::first_natural_join_processing flag has
  been added.
sql/sql_lex.h:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  The st_select_lex::first_natural_join_processing flag
  has been added to skip unnecessary rebuilding of
  NATURAL/USING JOIN structures during table reopening
  after lock_tables failure.
sql/sql_update.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Extra cleanup calls have been added to reset
  Natural_join_column::table_field items.
sql/table.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Type adjustment for Natural_join_column::table_field
  (Field to Item_field).
sql/table.h:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Type of the Natural_join_column::table_field field has
  been changed from Field that points into short-living
  TABLE memory to long-living Item_field that can be
  linked to (fixed) reopened table.

           columns data types

The "SELECT @lastId, @lastId := Id FROM t" query returns
different result sets depending on the type of the Id column
(INT or BIGINT).

Note: this fix doesn't cover the case when a select query
references an user variable and stored function that
updates a value of that variable, in this case a result
is indeterminate.


The server uses incorrect assumption about a constantness of
an user variable value as a select list item: 

The server caches a last query number where that variable
was changed and compares this number with a current query
number. If these numbers are different, the server guesses,
that the variable is not updating in the current query, so
a respective select list item is a constant. However, in some
common cases the server updates cached query number too late.


The server has been modified to memorize user variable
assignments during the parse phase to take them into account
on the next (query preparation) phase independently of the
order of user variable references/assignments in a select
item list.


mysql-test/r/user_var.result:
  Added test case for bug #26020.
mysql-test/t/user_var.test:
  Added test case for bug #26020.
sql/item_func.cc:
  An update of entry and update_query_id variables has been
  moved from Item_func_set_user_var::fix_fields() to a separate
  method, Item_func_set_user_var::set_entry().
sql/item_func.h:
  1. The Item_func_set_user_var::set_entry() method has been
  added to update Item_func_set_user_var::entry.
  
  2. The Item_func_set_user_var::entry_thd field has beend
  added to update Item_func_set_user_var::entry only when
  needed.
sql/sql_base.cc:
  Fix: setup_fiedls() calls Item_func_set_user_var::set_entry()
  for all items from the thd->lex->set_var_list before the first
  call of ::fix_fields().
sql/sql_lex.cc:
  The lex_start function has been modified to reset
  the st_lex::set_var_list list.
sql/sql_lex.h:
  New st_lex::set_var_list field has been added to
  memorize all user variable assignments in the current
  select query.
sql/sql_yacc.yy:
  The variable_aux rule has been modified to memorize
  in-query user variable assignments in the
  st_lex::set_var_list list.

build)

The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)

The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.

The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.

Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.


mysql-test/r/parser_stack.result:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
mysql-test/t/parser_stack.test:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp_head.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_parse.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_prepare.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_trigger.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_view.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_yacc.yy:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)

enabled)

Before this fix, the lexer and parser would treat the ';' character as a
different token (either ';' or END_OF_INPUT), based on convoluted logic,
which failed in simple cases where a stored procedure is implemented as a
single statement, and used in a multi query.

With this fix:
- the character ';' is always parsed as a ';' token in the lexer,
- parsing multi queries is implemented in the parser, in the 'query:' rules,
- the value of thd->client_capabilities, which is the capabilities
  negotiated between the client and the server during bootstrap,
  is immutable and not arbitrarily modified during parsing (which was the
  root cause of the bug)

Mixing aggregate functions and non-grouping columns is not allowed in the
ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
of insufficient check.

In order to check more thoroughly the new algorithm employs a list of outer
fields used in a sum function and a SELECT_LEX::full_group_by_flag.
Each non-outer field checked to find out whether it's aggregated or not and
the current select is marked accordingly.
All outer fields that are used under an aggregate function are added to the
Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
function.


mysql-test/t/group_by.test:
  Added a test case for the bug#27219: Aggregate functions in ORDER BY.
mysql-test/r/group_by.result:
  Added a test case for the bug#27219: Aggregate functions in ORDER BY.
sql/sql_select.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Implementation of new check for mixing non aggregated fields and aggregation
  function in the ONLY_FULL_GROUP_BY mode.
sql/sql_lex.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Initialization of the full_group_by_flag bitmap.
  SELECT_LEX::test_limit function doesn't reset ORDER BY
  clause anymore.
sql/sql_lex.h:
  Bug#27219: Aggregate functions in ORDER BY.
  The full_group_by_flag is added to the SELECT_LEX class.
sql/item_sum.h:
  Bug#27219: Aggregate functions in ORDER BY.
  The outer_fields list is added to the Item_sum class.
sql/mysql_priv.h:
  Bug#27219: Aggregate functions in ORDER BY.
  Defined a set of constants used in the new check for mixing non aggregated
  fields and sum functions in the ONLY_FULL_GROUP_BY_MODE.
sql/item_subselect.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  The Item_in_subselect::select_in_like_transformer function now drops
  ORDER BY clause in all selects in a subquery.
sql/item_sum.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Now the Item_sum::check_sum_func function now checks whether fields in the
  outer_fields list are aggregated or not and marks selects accordingly.
sql/item.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Now the Item_field::fix_fields function checks whether the field is aggregated
  or not and marks its select_lex accordingly.

between 5.0 and 5.1.
  
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
  
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
  - be completely in UTF8;
  - not contain character set introducers.
  
For more information, see WL4052.


mysql-test/include/ddl_i18n.check_views.inc:
  Add a test case for Bug#30217.
mysql-test/r/ddl_i18n_koi8r.result:
  Update result file.
mysql-test/r/ddl_i18n_utf8.result:
  Update result file.
mysql-test/r/information_schema.result:
  Update result file.
mysql-test/r/information_schema_db.result:
  Update result file.
mysql-test/r/mysqldump.result:
  Update result file.
mysql-test/r/show_check.result:
  Update result file.
mysql-test/t/ddl_i18n_koi8r.test:
  Add a test case for Bug#30217.
mysql-test/t/ddl_i18n_utf8.test:
  Add a test case for Bug#30217.
mysql-test/t/mysqldump.test:
  Add a test case for Bug#30217.
sql/ha_ndbcluster.cc:
  Add a parameter to print().
sql/item.cc:
  1. Add a parameter to print().
  2. Item_string::print():
        - Do not append character set introducer to the text literal
          if we're building a query for INFORMATION_SCHEMA;
        - Convert text literal to UTF8 if we're building a query
          for INFORMATION_SCHEMA.
sql/item.h:
  Add a parameter to print().
sql/item_cmpfunc.cc:
  Add a parameter to print().
sql/item_cmpfunc.h:
  Add a parameter to print().
sql/item_func.cc:
  Add a parameter to print().
sql/item_func.h:
  Add a parameter to print().
sql/item_geofunc.h:
  Add a parameter to print().
sql/item_row.cc:
  Add a parameter to print().
sql/item_row.h:
  Add a parameter to print().
sql/item_strfunc.cc:
  Add a parameter to print().
sql/item_strfunc.h:
  Add a parameter to print().
sql/item_subselect.cc:
  Add a parameter to print().
sql/item_subselect.h:
  Add a parameter to print().
sql/item_sum.cc:
  Add a parameter to print().
sql/item_sum.h:
  Add a parameter to print().
sql/item_timefunc.cc:
  Add a parameter to print().
sql/item_timefunc.h:
  Add a parameter to print().
sql/mysql_priv.h:
  Add a parameter to print().
sql/sp_head.cc:
  Add a parameter to print().
sql/sql_lex.cc:
  Add a parameter to print().
sql/sql_lex.h:
  Add a parameter to print().
sql/sql_parse.cc:
  Add a parameter to print().
sql/sql_select.cc:
  Add a parameter to print().
sql/sql_show.cc:
  Add a parameter to print().
sql/sql_test.cc:
  Add a parameter to print().
sql/sql_view.cc:
  Build INFORMATION_SCHEMA query from Item-tree.
sql/sql_yacc.yy:
  Build INFORMATION_SCHEMA query from Item-tree.
sql/table.h:
  Add a parameter to print().

            partitioned table

Trying INSERT DELAYED on a partitioned table, that has not been
used right before, crashes the server. When a table is used for
select or update, it is kept open for some time. This period I
mean with "right before".

Information about partitioning of a table is stored in form of
a string in the .frm file. Parsing of this string requires a
correctly set up lexical analyzer (lex). The partitioning code
uses a new temporary instance of a lex. But it does still refer
to the previously active lex. The delayd insert thread does not
initialize its lex though...

Added initialization for thd->lex before open table in the delayed
thread and at all other places where it is necessary to call
lex_start() if all tables would be partitioned and need to parse
the .frm file.


mysql-test/r/partition_hash.result:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Added test result
mysql-test/t/partition_hash.test:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Added test
sql/event_scheduler.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/events.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/ha_ndbcluster_binlog.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/slave.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/sql_acl.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/sql_base.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Asserted that lex is initialized in open_table().
sql/sql_connect.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/sql_insert.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Added initialization for thd->lex before open table.
sql/sql_lex.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Added 'is_lex_started' to test if lex is initialized.
sql/sql_lex.h:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Added 'is_lex_started' to test if lex is initialized.
sql/sql_plugin.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/sql_servers.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/sql_udf.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().
sql/table.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Asserted that lex is initialized in open_table_from_share().
sql/tztime.cc:
  Bug#31210 - INSERT DELAYED crashes server when used on
              partitioned table
  Initialized lex for later use in open_table().

Problem: creating a partitioned table during name resolution for the 
partition function we search for column names in all parts of the
CREATE TABLE query. It is superfluous (and wrong) sometimes.

Fix: launch name resolution for the partition function against
the table we're creating.


mysql-test/r/partition.result:
  Fix for bug #29444: crash with partition refering to table in create-select
    - test result.
mysql-test/t/partition.test:
  Fix for bug #29444: crash with partition refering to table in create-select
    - test result.
sql/item.cc:
  Fix for bug #29444: crash with partition refering to table in create-select
    - LEX::use_only_table_context introduced, which is used in the 
      Item_field::fix_fields() to resolve names only against
      context->first_name_resolution_table/last_name_resolution_table.
sql/sql_lex.cc:
  Fix for bug #29444: crash with partition refering to table in create-select
    - LEX::use_only_table_context introduced, which is used in the 
      Item_field::fix_fields() to resolve names only against
      context->first_name_resolution_table/last_name_resolution_table.
sql/sql_lex.h:
  Fix for bug #29444: crash with partition refering to table in create-select
    - LEX::use_only_table_context introduced, which is used in the 
      Item_field::fix_fields() to resolve names only against
      context->first_name_resolution_table/last_name_resolution_table.
sql/sql_partition.cc:
  Fix for bug #29444: crash with partition refering to table in create-select
    - set the lex->use_only_table_context before the func_expr->fix_fields()
      call to ensure we're resolving names against the table we're creating;
      then restore it back after the call.

 The parser uses ulonglong to store the LIMIT number. This number
 then is stored into a variable of type ha_rows. ha_rows is either
 4 or 8 byte depending on the BIG_TABLES define from config.h
 So an overflow may occur (and LIMIT becomes zero) while storing an
 ulonglong value in ha_rows.
 Fixed by :
  1. Using the maximum possible value for ha_rows on overflow
  2. Defining BIG_TABLES for the windows builds (to match the others) 


include/config-win.h:
  Bug #30639: turn on BIG_TABLES for windows
mysql-test/r/select.result:
  Bug #30639: test case
mysql-test/t/select.test:
  Bug #30639: test case
sql/sql_lex.cc:
  Bug #30639: Use the maximum possible number on overflow 
   of LIMIT. This is valid because there won't be more rows
   anyway.

comments)

This change set is for 5.1 (manually merged)

Before this fix, the server would accept queries that contained comments,
even when the comments were not properly closed with a '*' '/' marker.

For example,
  select 1 /* + 2 <EOF>
would be accepted as
  select 1 /* + 2 */ <EOF>
and executed as
  select 1

With this fix, the server now rejects queries with unclosed comments
as syntax errors.
Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
closed with '*' '/' to be parsed correctly.


mysql-test/r/comments.result:
  Unbalanced comments are a syntax error.
mysql-test/t/comments.test:
  Unbalanced comments are a syntax error.
sql/sql_lex.cc:
  Unbalanced comments are a syntax error.

comments)

Before this fix, the server would accept queries that contained comments,
even when the comments were not properly closed with a '*' '/' marker.

For example,
  select 1 /* + 2 <EOF>
would be accepted as
  select 1 /* + 2 */ <EOF>
and executed as
  select 1

With this fix, the server now rejects queries with unclosed comments
as syntax errors.
Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
closed with '*' '/' to be parsed correctly.


mysql-test/r/comments.result:
  Unbalanced comments are a syntax error.
mysql-test/t/comments.test:
  Unbalanced comments are a syntax error.
sql/sql_lex.cc:
  Unbalanced comments are a syntax error.

Recommit to 5.1.22.
The bug caused memory corruption for some queries with top OR level
in the WHERE condition if they contained equality predicates and 
other sargable predicates in disjunctive parts of the condition.

The corruption happened because the upper bound of the memory
allocated for KEY_FIELD and SARGABLE_PARAM internal structures
containing info about potential lookup keys was calculated incorrectly
in some cases. In particular it was calculated incorrectly when the
WHERE condition was an OR formula with disjuncts being AND formulas
including equalities and other sargable predicates.


mysql-test/r/select.result:
  Added a test case for bug #30396.
  Recommit to 5.1.22.
mysql-test/t/select.test:
  Added a test case for bug #30396.
  Recommit to 5.1.22.
sql/item_cmpfunc.h:
  Removed max_members from the COND_EQUAL class as not useful anymore. 
  Recommit to 5.1.22.
sql/sql_base.cc:
  Added the max_equal_elems field to the st_select_lex structure.
  Recommit to 5.1.22.
sql/sql_lex.cc:
  Added the max_equal_elems field to the st_select_lex structure.
  Recommit to 5.1.22.
sql/sql_lex.h:
  Added the max_equal_elems field to the st_select_lex structure.
  The field contains the maximal number of elements in multiple equalities
  built for the query conditions.
  Recommit to 5.1.22.
sql/sql_select.cc:
  Fixed bug #30396.
  Recommit to 5.1.22.
  The bug caused memory corruption for some queries with top OR level
  in the WHERE condition if they contained equality predicates and 
  other sargable predicates in disjunctive parts of the condition.
  
  The corruption happened because the upper bound of the memory
  allocated for KEY_FIELD and SARGABLE_PARAM internal structures
  containing info about potential lookup keys was calculated incorrectly
  in some cases. In particular it was calculated incorrectly when the
  WHERE condition was an OR formula with disjuncts being AND formulas
  including equalities and other sargable predicates.
   
  The max_equal_elems field to the st_select_lex structure is used now
  to calculate the above mentioned upper bound. The field contains the
  maximal number of elements in multiple equalities built for the query
  conditions.

Before this patch, the parser would execute:
- Select->expr_list.push_front()
- Select->expr_list.pop()
when parsing expressions lists, in the following rules:
- udf_expr_list
- expr_list
- ident_list

This is unnecessary, and introduces overhead due to the memory allocations
performed with Select->expr_list

With this patch, this code has been removed.
The list being parsed is maintained in the parser stack instead.

Also, 'udf_expr_list' has been renamed 'opt_udf_expr_list', since this
production can be empty.


sql/sql_lex.cc:
  Removed unused attribute expr_list
sql/sql_lex.h:
  Removed unused attribute expr_list
sql/sql_yacc.yy:
  Improved performances when parsing expression lists

The bug caused memory corruption for some queries with top OR level
in the WHERE condition if they contained equality predicates and 
other sargable predicates in disjunctive parts of the condition.

The corruption happened because the upper bound of the memory
allocated for KEY_FIELD and SARGABLE_PARAM internal structures
containing info about potential lookup keys was calculated incorrectly
in some cases. In particular it was calculated incorrectly when the
WHERE condition was an OR formula with disjuncts being AND formulas
including equalities and other sargable predicates.


mysql-test/r/select.result:
  Added a test case for bug #30396.
mysql-test/t/select.test:
  Added a test case for bug #30396.
sql/item_cmpfunc.h:
  Removed max_members from the COND_EQUAL class as not useful anymore.
sql/sql_base.cc:
  Added the max_equal_elems field to the st_select_lex structure.
sql/sql_lex.cc:
  Added the max_equal_elems field to the st_select_lex structure.
sql/sql_lex.h:
  Added the max_equal_elems field to the st_select_lex structure.
  The field contains the maximal number of elements in multiple equalities
  built for the query conditions.
sql/sql_select.cc:
  Fixed bug #30396.
  The bug caused memory corruption for some queries with top OR level
  in the WHERE condition if they contained equality predicates and 
  other sargable predicates in disjunctive parts of the condition.
  
  The corruption happened because the upper bound of the memory
  allocated for KEY_FIELD and SARGABLE_PARAM internal structures
  containing info about potential lookup keys was calculated incorrectly
  in some cases. In particular it was calculated incorrectly when the
  WHERE condition was an OR formula with disjuncts being AND formulas
  including equalities and other sargable predicates.
   
  The max_equal_elems field to the st_select_lex structure is used now
  to calculate the above mentioned upper bound. The field contains the
  maximal number of elements in multiple equalities built for the query
  conditions.