Merge Facebook commit 926a077b14b73c14094de7fc7aa913241b801b4d
authored by Inaam Rana from https://github.com/facebook/mysql-5.6.

This is fix for upstream bugs
http://bugs.mysql.com/bug.php?id=71988
http://bugs.mysql.com/bug.php?id=70500

page_cleaner should work whether or not there is server activity.
Its iterations become a noop when there is no work to do but we
should not tie it to the server activity.

The page_cleaner thread does spurious background flushing
because of conditional sleep between iterations. The solution
is not to make sleep dependent on server activity etc.

Merged Facebooks commit 6e06bbfa315ffb97d713dd6e672d6054036ddc21
authored by Inaam Rana from https://github.com/facebook/mysql-5.6.

Fixes MySQL bug http://bugs.mysql.com/bug.php?id=72123

lock_timeout thread works in a tight loop waking up every second
and checking for lock_wait_timeout. In addition, when a mysql
thread is forced to wait on a lock, it signals the lock_timeout thread
as well. This call is not required. In a heavily contended workload
each thread going to wait will signal the lock_timeout thread making
it work all the time. As lock_timeout thread scans the array of
waiting threads under lock_sys::wait_mutex which is already very
hot in contneded loads, these extra scans can cause significanct
performance regression.

Also, in various codepaths lock_timeout thread is signalled where
actual intention was to signal the innodb monitor thread.

Merged Facebook commit bdab302a7e3c37da21a1bffe1550cdbe6c906695
by Inaam Rana from https://github.com/facebook/mysql-5.6.

In os_event_wait_time_low() the logic to calculate abs_time
for wait is broken. The bug has been present at least since
5.5. It gets acutely sensitized when sub-second wait intervals
are passed. It is particularly relevant to us because the
page_cleaner thread will mostly request sub-second wait
intervals. This can potentially lead to a near tight loop
behaviour of page_cleaner with much less sleep then what we'd
actually expect.

(Attempt #2)
- Don't attempt to use BKA for materialized derived tables. The 
  table is neither filled nor fully opened yet, so attempt to 
  call handler->multi_range_read_info() causes crash.

- Don't attempt to use BKA for materialized derived tables. The 
  table is neither filled nor fully opened yet, so attempt to 
  call handler->multi_range_read_info() causes crash.

- Make Mrr_ordered_index_reader::resume_read() restore index position 
  only if it was saved before with Mrr_ordered_index_reader::interrupt_read().

modified:
  storage/connect/tabodbc.cpp

modified:
  storage/connect/ha_connect.cc
  storage/connect/plgdbutl.cpp
  storage/connect/value.cpp
  storage/connect/value.h

- calculate_cond_selectivity_for_table() should handle the case
  where index statistics is not available (zeros are returned 
  in rec_per_key)

  Was added to ha_connect::GetBooleanOption (otherwise ignored)
modified:
  storage/connect/ha_connect.cc

  terminated string.
modified:
  storage/connect/ha_connect.cc

- The Accept and Header Boolean variables were wrongly retrieved using
  GetIntInfo instead of GetBoolInfo causing some setting to ignored.
modified:
  storage/connect/tabdos.cpp
  storage/connect/tabdos.h
  storage/connect/tabfmt.cpp

- Fix date truncated because their Value class was not using their field length.
modified:
  storage/connect/ha_connect.cc

GRN_SET_64BIT.

revno: 4301
committer: Alexey Botchkov <holyfoot@askmonty.org>
branch nick: 10exp
timestamp: Tue 2014-07-22 15:28:15 +0500
message:
  gis-precise.test fixed to work on Power8.
------------------------------------------------------------
revno: 4295
committer: Alexey Botchkov <holyfoot@askmonty.org>
branch nick: 10exp
timestamp: Mon 2014-07-21 13:07:48 +0500
message:
  gis-precise test fixed to pass on Power8.