1. 07 Oct, 2009 1 commit
  2. 05 Oct, 2009 2 commits
  3. 02 Oct, 2009 2 commits
  4. 01 Oct, 2009 4 commits
  5. 30 Sep, 2009 4 commits
    • Joerg Bruehe's avatar
      Merge "trunk-build" up into "next-mr". · 3fddd102
      Joerg Bruehe authored
      3fddd102
    • Ingo Struewing's avatar
      auto-merge · 1f49cf74
      Ingo Struewing authored
      1f49cf74
    • Ingo Struewing's avatar
      Bug#37267 - connect() EINPROGRESS failures mishandled in client library · 7dacca0f
      Ingo Struewing authored
      We cann connect() in a non-blocking mode to be able to specify a
      non-standard timeout.
      
      The problem was that we did not fetch the status from the
      non-blocking connect(). We assumed that poll() would not return
      a POLLIN flag if the connect failed. But on some platforms this
      is not true.
      
      After a successful poll() we do now retrieve the status value
      from connect() with getsockopt(...SO_ERROR...). Now we do know
      if (and how) the connect failed.
      
      The test case for my investigation was rpl.rlp_ssl1 on an
      Ubuntu 9.04 x86_64 machine. Both, IPV4 and IPV6 were active.
      'localhost' resolved first for IPV6 and then for IPV4. The
      connection over IPV6 was blocked. rpl.rlp_ssl1 timed out
      as it did not notice the failed connect(). The first read()
      failed, which was interpreted as a master crash and the
      connection was tried to reestablish with the same result
      until the retry limit was reached.
      
      With the fix, the connect() problem is immediately recognized,
      and the connect() is retried on the second resolution for
      'localhost', which is successful.
      
      
      libmysqld/libmysqld.c:
        Bug#37267 - connect() EINPROGRESS failures mishandled in client library
        Changed a DBUG print string to distinguish the two mysql_real_connect()
        implementations in DBUG traces.
      mysql-test/include/wait_for_slave_param.inc:
        Bug#37267 - connect() EINPROGRESS failures mishandled in client library
        Made timeout value available in error message.
      mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
        Bug#37267 - connect() EINPROGRESS failures mishandled in client library
        Fixed test result. Connect error is now detected as CR_CONN_HOST_ERROR
        (2003) instead of CR_SERVER_LOST (2013).
      sql-common/client.c:
        Bug#37267 - connect() EINPROGRESS failures mishandled in client library
        Added retrieval of the error code from the non-blocking connect().
        Added DBUG.
        Added comment.
      7dacca0f
    • Guilhem Bichot's avatar
      Fix for BUG#42980 "Client doesn't set NUM_FLAG for DECIMAL and TIMESTAMP": · 12e82203
      Guilhem Bichot authored
      DECIMAL and TIMESTAMP used to have NUM_FLAG, but NEWDECIMAL was forgotten.
      It's correct that TIMESTAMP does not have the flag nowadays (manual will be updated, connectors
      developers will be notified).
      
      client/mysqldump.c:
        IS_NUM_FIELD(f) removed and replaced by its definition (f>flags & NUM_FLAG).
      include/mysql.h:
        - IS_NUM_FIELD() is removed because name is too close to IS_NUM() and it is not used a lot
        - INTERNAL_NUM_FIELD() is removed:
          * it forgets to test NEWDECIMAL (when IS_NUM() was updated for NEWDECIMAL we forgot
          to update INTERNAL_NUM_FIELD()), that's why client didn't mark NEWDECIMAL with NUM_FLAG (a bug).
          * it has an obsolete test for length of the TIMESTAMP field: test became accidentally wrong when length
          of TIMESTAMP was changed to always be 19 (when the format was changed from YYYYMMDDhhmmss to
          YYYY-MM-DD hh:mm:ss), never 8 or 14 anymore. That obsolete test caused TIMESTAMP to lose NUM_FLAG,
          which was an accidental but good change (see below).
          * IS_NUM() should be used instead
        - IS_NUM(f) is changed: TIMESTAMP used to be parsable as a number without quotes (when it was formatted as
        "YYYYMMDDhhmmss"); but it is not anymore (now that it is "YYYY-MM-DD hh:mm:ss"), so it should not have NUM_FLAG
        (mysqldump needs to quote TIMESTAMP values), so IS_NUM() should return false for it.
      libmysqld/lib_sql.cc:
        use IS_NUM() instead of INTERNAL_NUM_FIELD()
      mysql-test/r/bigint.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/r/metadata.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/r/mysqldump.result:
        DECIMAL columns are not quoted anymore by mysqldump. Which is ok, the parser does not need '' for them
      mysql-test/r/ps_2myisam.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/r/ps_3innodb.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/r/ps_4heap.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/r/ps_5merge.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/suite/ndb/r/ps_7ndb.result:
        result change: NEWDECIMAL fields now have NUM_FLAG (32768)
      mysql-test/t/metadata.test:
        test for BUG#42980
      sql-common/client.c:
        use IS_NUM() instead of INTERNAL_NUM_FIELD()
      12e82203
  6. 29 Sep, 2009 1 commit
  7. 28 Sep, 2009 6 commits
  8. 27 Sep, 2009 1 commit
  9. 25 Sep, 2009 7 commits
  10. 24 Sep, 2009 5 commits
  11. 23 Sep, 2009 7 commits