to crash) from mysql-6.0-codebase.

The thing is that on some platforms (e.g. Mac OS X) sockaddr_in / sockaddr_in6
contain a non-standard field (sin_len / sin6_len), that must be set.

The problem was that only standard fields were set, thus getnameinfo() returned
EAI_SYSTEM instead of EAI_NONAME.

The fix is to introduce configure-time checks (for GNU auto-tools and CMake) for
those additional fields and to set them if they are available.

FOR UPDATE is causing a lock".
 
This patch tries to address problems which were exposed 
during backporting of original patch to 5.1 tree.
 
- It ensures that we don't change locking behavior of simple
  SELECT statements on InnoDB tables when they are executed
  under LOCK TABLES ... READ and with @@innodb_table_locks=0.
  Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT 
  lock types, which are supposed to be parser-only, to 
  handler::start_stmt() method.
- It makes check_/no_concurrent_insert.inc auxiliary scripts 
  more robust against changes in test cases that use them
  and also ensures that they don't unnecessarily change 
  environment of caller.

mysql-test/include/check_concurrent_insert.inc:
  Reset DEBUG_SYNC facility before and after using it in
  auxiliary script. This makes this script more robust against
  changes in test cases calling it. It also ensures that script
  does not unnecessarily change environment of caller.
mysql-test/include/check_no_concurrent_insert.inc:
  Reset DEBUG_SYNC facility before and after using it in
  auxiliary script. This makes this script more robust against
  changes in test cases calling it. It also ensures that script
  does not unnecessarily change environment of caller.
mysql-test/r/innodb-lock.result:
  Added coverage for LOCK TABLES ... READ behavior in
  @@innodb_table_locks = 0 mode. This test also checks
  that an appropriate type of lock is passed to
  handler::start_stmt() method.
mysql-test/t/innodb-lock.test:
  Added coverage for LOCK TABLES ... READ behavior in
  @@innodb_table_locks = 0 mode. This test also checks
  that an appropriate type of lock is passed to
  handler::start_stmt() method.
sql/sql_base.cc:
  Since we no longer set TL_READ as lock type for tables used  
  in simple SELECT right in the parser, in order to preserve  
  behavior for such statements on InnoDB tables when in  
  LOCK TABLES mode with @innodb_table_locks = 0,  
  check_lock_and_start_stmt() had to be changed to convert  
  TL_READ_DEFAULT to an appropriate type of read lock before  
  passing it to handler::start_stmt() method.  
  We do similar thing for TL_WRITE_DEFAULT as this lock type  
  is also supposed to be parser-only type.  
  As consequence read_lock_type_for_table() had to be  
  adjusted to behave properly when it is called from  
  check_lock_and_start_stmt() in prelocked mode.

(make relies GNU extentions). The patch was partially
backport from 6.0.

Original comment:
bug#30708: make relies GNU extensions.  Now that we no longer use
BitKeeper we can safely remove the SCCS handling with no loss of
functionality.

from 6.0 to trunk-bugfixing.

The problem was that OPTMIZE TABLE was allowed to run on a table
in use by a transaction in a different connection. This caused
repeatable read to break.

This bug was fixed by the introduction of metadata locking, WL#4284.
OPTIMIZE TABLE will now be blocked until the transaction using the
table, has ended.

This patch contains a regression test added to innodb_mysql_lock.test
and no code changes.

bug. The code has been changed to work around it. To reprocude the bug simply
revert this change and build the binary with:

GCC Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5659~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5659)

export LDFLAGS='-g -arch i386'
export CFLAGS='-g -no-cpp-precomp -arch i386 -O2'
export CXXFLAGS='-g -no-cpp-precomp -arch i386 -O2'

./configure --enable-thread-safe-client --enable-local-infile --with-pic --with-client-ldflags=-static --with-mysqld-ldflags=-static --with-zlib-dir=bundled --without-ndb-debug --with-big-tables --with-ssl --with-readline --with-embedded-server --with-archive-storage-engine --with-blackhole-storage-engine --with-csv-storage-engine --with-example-storage-engine --with-federated-storage-engine --with-partition --with-extra-charsets=all --with-innodb --with-ndbcluster --with-libevent --target=i386-apple-darwin --program-transform-name=

Approved by Marko on IM.

------------------------------------------------------------
revno: 3472
revision-id: marko.makela@oracle.com-20100519080743-5myf1g7v6pfysidt
parent: marko.makela@oracle.com-20100519080152-h3555oqmu3wo95so
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: 5.1-innodb
timestamp: Wed 2010-05-19 11:07:43 +0300
message:
  Make UNIV_DEBUG Valgrind friendly. Use | instead of +,
  and mask out the dont-care bits in debug assertions.

------------------------------------------------------------
revno: 3471
revision-id: marko.makela@oracle.com-20100519080152-h3555oqmu3wo95so
parent: marko.makela@oracle.com-20100519075843-4gl3uijo6cwjtcf9
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: 5.1-innodb
timestamp: Wed 2010-05-19 11:01:52 +0300
message:
  Silence some more bogus Valgrind warnings on non-32-bit systems. (Bug #53307)

Author:	Marko

==31182== Conditional jump or move depends on uninitialised value(s)
==31182==    at 0xA9188B: longest_match (deflate.c:1143)
==31182==    by 0xA92C19: deflate_slow (deflate.c:1595)
==31182==    by 0xA90C6B: deflate (deflate.c:790)
==31182==    by 0x9B447B: page_zip_compress (page0zip.c:1342)
==31182==    by 0x9A8540: page_cur_insert_rec_zip_reorg (page0cur.c:1174)
==31182==    by 0x9A8998: page_cur_insert_rec_zip (page0cur.c:1279)
==31182==    by 0x9214F9: page_cur_tuple_insert (page0cur.ic:264)
==31182==    by 0x9221A2: btr_cur_optimistic_insert (btr0cur.c:1314)
==31182==    by 0x9C99EB: row_ins_index_entry_low (row0ins.c:2087)
==31182==    by 0x9C9DFB: row_ins_index_entry (row0ins.c:2167)
==31182==    by 0x9CA057: row_ins_index_entry_step (row0ins.c:2252)
==31182==    by 0x9CA0FD: row_ins (row0ins.c:2384)
==31182==    by 0x9CA760: row_ins_step (row0ins.c:2494)
==31182==    by 0x8CBF7E: row_insert_for_mysql (row0mysql.c:1138)
==31182==    by 0x8BCF32: ha_innobase::write_row(unsigned char*) (ha_innodb.cc:4929)
==31182==    by 0x736E03: handler::ha_write_row(unsigned char*) (handler.cc:4682)

innodb.innodb-zip                        [ fail ]  Found warnings/errors in server log file!
        Test ended at 2010-05-17 16:41:25
line
==31182== Thread 13:
==31182== Conditional jump or move depends on uninitialised value(s)
==31182==    at 0xA9193F: longest_match (deflate.c:1143)
==31182==    by 0xA92C19: deflate_slow (deflate.c:1595)
==31182==    by 0xA90C6B: deflate (deflate.c:790)
==31182==    by 0x928A07: btr_store_big_rec_extern_fields (btr0cur.c:4092)
==31182==    by 0x9C9B90: row_ins_index_entry_low (row0ins.c:2119)
==31182==    by 0x9C9DFB: row_ins_index_entry (row0ins.c:2167)
==31182==    by 0x9CA057: row_ins_index_entry_step (row0ins.c:2252)
==31182==    by 0x9CA0FD: row_ins (row0ins.c:2384)
==31182==    by 0x9CA760: row_ins_step (row0ins.c:2494)
==31182==    by 0x8CBF7E: row_insert_for_mysql (row0mysql.c:1138)
==31182==    by 0x8BCF32: ha_innobase::write_row(unsigned char*) (ha_innodb.cc:4929)
==31182==    by 0x736E03: handler::ha_write_row(unsigned char*) (handler.cc:4682)
==31182==    by 0x5B0EEE: write_record(THD*, TABLE*, st_copy_info*) (sql_insert.cc:1670)
==31182==    by 0x5B129D: select_insert::send_data(List<Item>&) (sql_insert.cc:3279)
==31182==    by 0x5F31ED: end_send(JOIN*, st_join_table*, bool) (sql_select.cc:12428)
==31182==    by 0x5F9B9B: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:11632)

  ------------------------------------------------------------
  revno: 3468
  revision-id: marko.makela@oracle.com-20100518130658-rd00ql7h02ooakh1
  parent: marko.makela@oracle.com-20100514131050-mkhlvlui1u52irob
  committer: Marko Mäkelä <marko.makela@oracle.com>
  branch nick: 5.1-innodb
  timestamp: Tue 2010-05-18 16:06:58 +0300
  message:
    Work around Bug #53750 in innodb_bug48024.test

That was a pure test issue -- filter implementation in Perl did not work
on some platform (the bug occurred on Windows Server 2008 with
Cygwin Perl 5.10.0).

in a multiquery packet): fix NDB test failures.

rb://339, approved by Sunny Bains.

==2229== Uninitialised byte(s) found during client check request
==2229==    at 0x9A599D: buf_page_get_gen (buf0buf.c:3003)
==2229==    by 0x9D58CD: fsp_header_init (fsp0fsp.c:974)
==2229==    by 0x95BEAE: innobase_start_or_create_for_mysql (srv0start.c:1537)
==2229==    by 0x91DDBB: innobase_init(void*) (ha_innodb.cc:2409)
==2229==    by 0x73AF1F: ha_initialize_handlerton(st_plugin_int*) (handler.cc:475)
==2229==    by 0x5DBAE3: plugin_initialize(st_plugin_int*) (sql_plugin.cc:1057)
==2229==    by 0x5DD185: plugin_init(int*, char**, int) (sql_plugin.cc:1343)
==2229==    by 0x53830A: init_server_components() (mysqld.cc:4141)
==2229==    by 0x539048: mysqld_main(int, char**) (mysqld.cc:4742)
==2229==    by 0x52D412: main (main.cc:24)
==2229==  Address 0x998B00C is not stack'd, malloc'd or (recently) free'd
==2229== (Memcheck does not allow error to be suppressed)

Approved by:	Marko (rb://345)

removing disabled line for rpl_row_create_table  due to Bug#45576. Anyway, the test is still there because of Bug#51574

pushing to next-mr-bugfixing from working branch

multiquery packet).

Background:

  - a query can contain multiple SQL statements;

  - the server frees resources allocated to process a query when the
    whole query is handled. In other words, resources allocated to process
    one SQL statement from a multi-statement query are freed when all SQL
    statements are handled.

The problem was that the parser allocated a buffer of size of the whole
query for each SQL statement in a multi-statement query. Thus, if a query
had many SQL-statements (so, the query was long), but each SQL statement
was short, ther parser tried to allocate huge amount of memory (number of
small SQL statements * length of the whole query).

The memory was allocated for a so-called "cpp buffer", which is intended to
store pre-processed SQL statement -- SQL text without version specific
comments.

The fix is to allocate memory for the "cpp buffer" once for all SQL
statements (once for a query).

approved):

3161 Vladislav Vaintroub       2010-04-29                 
 Bug#53196 : CMake builds don't support 'make tags' and 
'make ctags' targets.  
   - Added tags and ctags targets


CMakeLists.txt:
  Add tags and ctags targets.
cmake/Makefile.am:
  Add a cmake file to build tags.
cmake/tags.cmake:
  Build tags and ctags.

to own the kernel mutex in fill_trx_row().

Post-merge fixes: Remove the MYSQL_VERSION_ID checks, because they only
apply to the InnoDB Plugin. Fix potential race condition accessing
trx->op_info and trx->detailed_error.
------------------------------------------------------------
revno: 3466
revision-id: marko.makela@oracle.com-20100514130815-ym7j7cfu88ro6km4
parent: marko.makela@oracle.com-20100514130228-n3n42nw7ht78k0wn
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: mysql-5.1-innodb2
timestamp: Fri 2010-05-14 16:08:15 +0300
message:
  Make the InnoDB FOREIGN KEY parser understand multi-statements. (Bug #48024)
  Also make InnoDB thinks that /*/ only starts a comment. (Bug #53644).

  This fixes the bugs in the InnoDB Plugin.

  ha_innodb.h: Use trx_query_string() instead of trx_query() when
  available (MySQL 5.1.42 or later).

  innobase_get_stmt(): New function, to retrieve the currently running
  SQL statement.

  struct trx_struct: Remove mysql_query_str. Use innobase_get_stmt() instead.

  dict_strip_comments(): Add and observe the parameter sql_length. Treat
  /*/ as the start of a comment.

  dict_create_foreign_constraints(), row_table_add_foreign_constraints():
  Add the parameter sql_length.

for ALTER TABLE, LOAD DATA).

ROW_COUNT is now assigned according to the following rules:

  - In my_ok():
    - for DML statements: to the number of affected rows;
    - for DDL statements: to 0.

  - In my_eof(): to -1 to indicate that there was a result set.

    We derive this semantics from the JDBC specification, where int
    java.sql.Statement.getUpdateCount() is defined to (sic) "return the
    current result as an update count; if the result is a ResultSet
    object or there are no more results, -1 is returned".

  - In my_error(): to -1 to be compatible with the MySQL C API and
    MySQL ODBC driver.

  - For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
    since that's the "default" value of ROW_COUNT in the diagnostics area.

sql/protocol.cc:
  Fix a typo.
sql/sql_class.h:
  - Introduce THD::get_row_count_func() / THD::set_row_count_func();
  - Remove the CF_HAS_ROW_COUNT define
sql/sql_parse.cc:
  CF_HAS_ROW_COUNT was eliminated.

type, which some time ago became part of Open_table_context class.
Apparently standalone enum type was erroneously re-introduced
during one of merges.