Iterative patch improvement. Previously committed patch
caused wrong result on Windows. The previous patch also
broke secure_file_priv for symlinks since not all file
paths which must be compared against this variable are
normalized using the same norm.

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.
     
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
      
It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.


mysql-test/r/loaddata.result:
  * Removed test code which will currently break the much used --mem feature of mtr.
mysql-test/t/loaddata.test:
  * Removed test code which will currently break the much used --mem feature of mtr.
sql/item_strfunc.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/mysql_priv.h:
  * Added signature for is_secure_file_path()
sql/mysqld.cc:
  * New function for checking if a path compatible with the secure path restriction.
  * Added initialization of the opt_secure_file_priv variable.
sql/sql_class.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/sql_load.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.

WHERE predicates containing references to empty tables in a
subquery were handled incorrectly by the optimizer when
executing EXPLAIN. As a result, the optimizer could try to
evaluate such predicates rather than just stop with
"Impossible WHERE noticed after reading const tables" as 
it would do in a non-subquery case. This led to valgrind 
errors and crashes.

Fixed the code checking the above condition so that subqueries
are not excluded and hence are handled in the same way as top
level SELECTs.

mysql-test/r/explain.result:
  Added a test case for bug #48419.
mysql-test/r/ps.result:
  Updated test results to take the new (and more correct)
  "Extra" comments in execution plans.
mysql-test/t/explain.test:
  Added a test case for bug #48419.
sql/sql_select.cc:
  There is no point in excluding subqueries from checking
  for identically false WHERE conditions.

mysql-tests because those emit (spurious?) valgrind warnings.

This addresses Bug #53122 in the built-in InnoDB.

recv_addr_t: Turn space,page_no into bitfields to save space on 64-bit.
This addresses Bug #53122 in the InnoDB Plugin.

READ COMMITTED in the built-in InnoDB. (Bug #48607)

The server could be tricked to read packets indefinitely if it
received a packet larger than the maximum size of one packet.
This problem is aggravated by the fact that it can be triggered
before authentication.

The solution is to no skip big packets for non-authenticated
sessions. If a big packet is sent before a session is authen-
ticated, a error is returned and the connection is closed.

include/mysql_com.h:
  Add skip flag. Only used in server builds.
sql/net_serv.cc:
  Control whether big packets can be skipped.

READ COMMITTED in the InnoDB Plugin. (Bug #48607)

Problem: "COM_FIELD_LIST is an old command of the MySQL server, before there was real move to only
SQL. Seems that the data sent to COM_FIELD_LIST( mysql_list_fields() function) is not
checked for sanity. By sending long data for the table a buffer is overflown, which can
be used deliberately to include code that harms".

Fix: check incoming data length.


sql/sql_parse.cc:
  Fix for bug #53237: mysql_list_fields/COM_FIELD_LIST stack smashing
    - check incoming mysql_list_fields() table name arg length.

on same table

Followup to vasil.dimov@oracle.com-20100428102033-dt3caf531rs3lidr :

Add more asserions, which I forgot.

This is branches/zip@r6032 in SVN and _is part_ of
revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:6113
in BZR.

This is being reverted because now the code is serialized directly on
index->stat_n_diff_key_vals[] as the fix for
Bug#53046 dict_update_statistics_low can still be run concurrently on same table
goes.

Address Marko's suggestions wrt the fix of
Bug#53046 dict_update_statistics_low can still be run concurrently
on same table

on same table

Protect dict_index_t::stat_n_diff_key_vals[] with an array of
mutexes.

Testing: tested all code paths under UNIV_SYNC_DEBUG
for the one in dict_print() one has to enable the InnoDB table monitor:
CREATE TABLE innodb_table_monitor (a int) ENGINE=INNODB;

  ------------------------------------------------------------------------
  r6103 | marko | 2009-10-26 15:46:18 +0200 (Mon, 26 Oct 2009) | 4 lines
  Changed paths:
     M /branches/zip/row/row0ins.c

  branches/zip: row_ins_alloc_sys_fields(): Zero out the system columns
  DB_TRX_ID, DB_ROLL_PTR and DB_ROW_ID, in order to avoid harmless
  Valgrind warnings about uninitialized data.  (The warnings were
  harmless, because the fields would be initialized at a later stage.)
  ------------------------------------------------------------------------

any files.

this results in some valgrind errors.

Bug#53202 valgrind: uninitialized bytes in dtuple_print()
has been opened to track this.

Extract part of innodb.innodb into innodb.innodb_misc1

This is needed in order to be able to more easily debug this test,
under valgrind, it is too huge.

The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.

Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().

mysql-test/r/join.result:
  Added a test case for bug #50335.
mysql-test/t/join.test:
  Added a test case for bug #50335.
sql/sql_select.cc:
  Removing the assertion in eq_ref_table() as it does not make
  any sense. We also have to take care of the 'found' counter so
  that we count multiple references only once. We rely on this
  fact later in eq_ref_table().

a transaction that holds a lock on a clustered index record
also holds a lock on the secondary index record.

They are only useful in table scans. (Bug #52663)

in MySQL 5.1.46.

about possibly uninitialized variable insert_left.

kill of active connection yields different error code
depending on platform.

When row_merge_drop_temp_indexes() was reworked to drop the indexes
via the data dictionary cache, the code was broken because it would
read the index name from the wrong field.

btr_page_tuple_smaller(): New function, refactored from
btr_page_split_and_insert().

btr_page_get_split_rec(): Renamed from btr_page_get_sure_split_rec().
Note that a NULL return may mean that the tuple is to be inserted into
either the lower or upper page, to be determined by btr_page_tuple_smaller().

btr_page_split_and_insert(): When btr_page_get_split_rec() returns NULL,
invoke btr_page_tuple_smaller() to determine which half-page the tuple
belongs to.

Reviewed by Sunny Bains

Bug #50495 is about REDUNDANT and COMPACT tables, after all.

when the data dictionary is locked.
This fixes a UNIV_DEBUG assertion failure in innodb-index.test.

is less than 256 bytes. (Bug #52745)
Add related comments and debug assertions to the "offsets"
functions in rem0rec.c.
Approved by Sunny Bains

The "extern" accessor functions return zero or nonzero, not 0 or 1.