Also explain in the comment the units of the "offset" parameter

It is wrong to tell the OS that a block is not going to be accessed and
write to it immediately afterwards.

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.

------------------------------------------------------------
revno: 3475
revision-id: marko.makela@oracle.com-20100520130734-ueow9mn60czp7o4m
parent: marko.makela@oracle.com-20100520104042-ma2nsscqdvwoph8k
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: 5.1-innodb
timestamp: Thu 2010-05-20 16:07:34 +0300
message:
  buf_LRU_free_block(): Correct an error in the comment.

TO DO: Enable this in CMake-based builds.

------------------------------------------------------------
revno: 3474
revision-id: marko.makela@oracle.com-20100520104042-ma2nsscqdvwoph8k
parent: marko.makela@oracle.com-20100519081618-h38q02qxuvcowbtk
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: 5.1-innodb
timestamp: Thu 2010-05-20 13:40:42 +0300
message:
  Bug#53593: Add some instrumentation to improve Valgrind sensitivity

  BUILD/*: Add valgrind_configs=--with-valgrind.
  BUILD/*: Remove -USAFEMALLOC from valgrind_flags.

  configure.in: Add AC_ARG_WITH(valgrind) and HAVE_VALGRIND.

  include/my_sys.h: Define a number of MEM_ wrappers for VALGRIND_ functions.
  include/my_sys.h: Make TRASH do MEM_UNDEFINED().

  include/m_string.h: Remove unused macro bzero_if_purify(A,B).

  _mymalloc(): Declare MEM_UNDEFINED() on the allocated memory.

  _myfree(): Declare MEM_NOACCESS() on the freed memory.

  storage/innobase/include/univ.i: Enable UNIV_DEBUG_VALGRIND based on
  HAVE_VALGRIND rather than HAVE_purify.

  Possible things to do:
   * In my_global.h, remove the defined(HAVE_purify) condition
     from the _WIN32 uint3korr().
   * In my_global.h *int*korr(), use | instead of +
     in order to keep the Valgrind V bits accurate
   * Consider replacing HAVE_purify with HAVE_VALGRIND
   * Use VALGRIND_CREATE_BLOCK, VALGRIND_DISCARD in mem_root and similar places

(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).