1. 25 Nov, 2014 3 commits
  2. 21 Nov, 2014 3 commits
  3. 20 Nov, 2014 1 commit
  4. 19 Nov, 2014 4 commits
    • Sergei Golubchik's avatar
      Fix YaSSL on windows · ed2cc2a8
      Sergei Golubchik authored
      This came with the upgrade from yassl 2.3.0 to 2.3.4 -
      ssl tests started to hang on Windows. Comparing and removing changes
      I've got to this:
      
       void input_buffer::set_current(uint i) 
       {
      -    if (i)
      -        check(i - 1, size_); 
      -    current_ = i; 
      +    if (error_ == 0 && i && check(i - 1, size_) == 0)
      +        current_ = i;
      +    else
      +        error_ = -1;
       }
      
      in 2.3.0 i==0 was only used to avoid the check, in 2.3.4 it's an error.
      but there are places in the code that do set_current(0) and others that
      do, like, { before=get_current(); ...; set_current(before); } - and the
      initial value of current_ is 0.
      
      So, I suspect that set_current(0) should not be an error, but it should
      only skip the check().
      ed2cc2a8
    • Sergei Golubchik's avatar
      MDEV-6975 Implement TLS protocol · d851d5e7
      Sergei Golubchik authored
      followup:
      * explicitly disable SSLv2 and SSLv3, keep other protocols enabled
      * fix a compiler warning
      * rename the test and combinations to avoid confusion
      
      vio/viossl.c:
        fix a compiler warning
      d851d5e7
    • Jan Lindström's avatar
      MDEV-7084: innodb index stats inadequate using constant · 8bc5eabe
      Jan Lindström authored
      innodb_stats_sample_pages
      
      Analysis: If you set the number of analyzed pages 
      to very low number compared to actual pages on 
      that table/index it randomly pics those pages 
      (default 8 pages), this leads to fact that query 
      after analyze table returns different results. If 
      the index tree is small, smaller than 10 * 
      n_sample_pages + total_external_size, then the 
      estimate is ok. For bigger index trees it is 
      common that we do not see any borders between 
      key values in the few pages we pick. But still 
      there may be n_sample_pages different key values, 
      or even more. And it just tries to 
      approximate to n_sample_pages (8).
      
      Fix: (1) Introduced new dynamic configuration variable
      innodb_stats_sample_traditional  that retains
      the current design. Default false.
      
      (2) If traditional sample is not used we use
      n_sample_pages = max(min(srv_stats_sample_pages,
                               index->stat_index_size),
                           log2(index->stat_index_size)*
                                srv_stats_sample_pages);
      
      (3) Introduced new dynamic configuration variable
      stat_modified_counter (default = 0) if set
      sets lower bound for row updates when statistics is re-estimated.
      
      If user has provided upper bound for how many rows needs to be updated
      before we calculate new statistics we use minimum of provided value
      and 1/16 of table every 16th round. If no upper bound is provided
      (srv_stats_modified_counter = 0, default) then calculate new statistics
      if 1 / 16 of table has been modified
      since the last time a statistics batch was run.
      We calculate statistics at most every 16th round, since we may have
      a counter table which is very small and updated very often.
      @param t table
      @return true if the table has changed too much and stats need to be
      recalculated
      */
      #define DICT_TABLE_CHANGED_TOO_MUCH(t) \
      	((ib_int64_t) (t)->stat_modified_counter > (srv_stats_modified_counter ? \
      	ut_min(srv_stats_modified_counter, (16 + (t)->stat_n_rows / 16)) : \
      		16 + (t)->stat_n_rows / 16))
      8bc5eabe
    • Kristian Nielsen's avatar
      MDEV-7026: Race in InnoDB/XtraDB mutex implementation can stall or hang the server. · 6ea41f1e
      Kristian Nielsen authored
      The bug was that full memory barrier was missing in the code that ensures that
      a waiter on an InnoDB mutex will not go to sleep unless it is guaranteed to be
      woken up again by another thread currently holding the mutex. This made
      possible a race where a thread could get stuck waiting for a mutex that is in
      fact no longer locked. If that thread was also holding other critical locks,
      this could stall the entire server. There is an error monitor thread than can
      break the stall, it runs about once per second. But if the error monitor
      thread itself got stuck or was not running, then the entire server could hang
      infinitely.
      
      This was introduced on i386/amd64 platforms in 5.5.40 and 10.0.13 by an
      incorrect patch that tried to fix the similar problem for PowerPC.
      
      This commit reverts the incorrect PowerPC patch, and instead implements a fix
      for PowerPC that does not change i386/amd64 behaviour, making PowerPC work
      similarly to i386/amd64.
      6ea41f1e
  5. 18 Nov, 2014 11 commits
  6. 15 Nov, 2014 1 commit
  7. 14 Nov, 2014 2 commits
  8. 13 Nov, 2014 4 commits
  9. 12 Nov, 2014 3 commits
  10. 10 Nov, 2014 3 commits
  11. 08 Nov, 2014 2 commits
  12. 17 Nov, 2014 3 commits