1. 29 Jul, 2006 6 commits
  2. 28 Jul, 2006 8 commits
  3. 27 Jul, 2006 4 commits
  4. 26 Jul, 2006 2 commits
    • tsmith/tim@siva.hindu.god's avatar
      Merge siva.hindu.god:/usr/home/tim/m/bk/global-41 · 80465ab6
      tsmith/tim@siva.hindu.god authored
      into  siva.hindu.god:/usr/home/tim/m/bk/global-50
      80465ab6
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21206: memory corruption when too many cursors are opened at once · 4e845ccc
      kroki/tomash@moonlight.intranet authored
      Too many cursors (more than 1024) could lead to memory corruption.
      This affects both, stored routines and C API cursors, and the
      threshold is per-server, not per-connection.  Similarly, the
      corruption could happen when the server was under heavy load
      (executing more than 1024 simultaneous complex queries), and this is
      the reason why this bug is fixed in 4.1, which doesn't support
      cursors.
      
      The corruption was caused by a bug in the temporary tables code, when
      an attempt to create a table could lead to a write beyond allocated
      space.  Note, that only internal tables were affected (the tables
      created internally by the server to resolve the query), not tables
      created with CREATE TEMPORARY TABLE.  Another pre-condition for the
      bug is TRUE value of --temp-pool startup option, which, however, is a
      default.
      
      The cause of a bug was that random memory was overwritten in
      bitmap_set_next() due to out-of-bound memory access.
      4e845ccc
  5. 25 Jul, 2006 3 commits
  6. 24 Jul, 2006 9 commits
  7. 23 Jul, 2006 1 commit
  8. 22 Jul, 2006 1 commit
  9. 21 Jul, 2006 2 commits
  10. 20 Jul, 2006 3 commits
  11. 19 Jul, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and a test case for Bug#21002 "Derived table not selecting from a · f22a4ce1
      kostja@bodhi.local authored
      "real" table fails in JOINs".
      
      This is a regression caused by the fix for Bug 18444. 
      This fix removed the assignment of empty_c_string to table->db performed 
      in add_table_to_list, as neither me nor anyone else knew what it was 
      there for. Now we know it and it's covered with tests: the only case 
      when a table database name can be empty is when the table is a derived 
      table. The fix puts the assignment back but makes it a bit more explicit.
      
      Additionally, finally drop sp.result.orig which was checked in by mistake. 
      f22a4ce1