1. 22 May, 2001 1 commit
  2. 19 May, 2001 3 commits
  3. 18 May, 2001 6 commits
  4. 17 May, 2001 1 commit
  5. 16 May, 2001 8 commits
  6. 15 May, 2001 3 commits
  7. 14 May, 2001 5 commits
  8. 13 May, 2001 3 commits
  9. 12 May, 2001 1 commit
  10. 11 May, 2001 4 commits
  11. 10 May, 2001 3 commits
    • sasha@mysql.sashanet.com's avatar
      sql/mysqld.cc · 4e04aa4a
      sasha@mysql.sashanet.com authored
          put back the things that the merge removed
      4e04aa4a
    • sasha@mysql.sashanet.com's avatar
      merged · c77547ea
      sasha@mysql.sashanet.com authored
      c77547ea
    • sasha@mysql.sashanet.com's avatar
      stack trace updates: · e809e2df
      sasha@mysql.sashanet.com authored
      limited support on Alpha - in general case, even with frame pointer,
      stack trace on alpha is impossible without looking at the symbol table
      frame pointer does get saved on the stack, but you have no idea where
      and where the return address is saved. So the best we can do without
      the symbol table is look for magic opcodes and try to guess how big 
      each frame is and where the return address was hidden from the 
      instruction parameters. In practice, we can usually go up 3-4 frames 
      before we hit some nasty frame that the current code cannot figure
      out. This is actually not too bad, especially when we already have the query
      
      Also cleaned up messages, print more variables, tell the user of
      how much memory mysqld could potentially use, and warn of
      what can happen with default STACK_SIZE and a lot of connections if
      coredump happens when there are more than 200 connections. 
      e809e2df
  12. 09 May, 2001 2 commits