1. 17 Jul, 2018 9 commits
    • antirez's avatar
      6201f7b4
    • Salvatore Sanfilippo's avatar
      Merge pull request #5136 from 0xtonyxia/fix-xread-id-parse · 4bff45c7
      Salvatore Sanfilippo authored
      Fix xreadgroup with '$' ID.
      4bff45c7
    • antirez's avatar
      Panic when we are sending an error to our master/slave. · afc7e08a
      antirez authored
      Related to #5135, see discussion there.
      afc7e08a
    • Salvatore Sanfilippo's avatar
      Merge pull request #5135 from oranagra/rare_repl_corruption · e03358c0
      Salvatore Sanfilippo authored
      fix rare replication stream corruption with disk-based replication
      e03358c0
    • dejun.xdj's avatar
      Streams: remove meaningless if condition. · 846cf12a
      dejun.xdj authored
      It's already checked if xreadgroup is set and groupname is NULL.
      846cf12a
    • dejun.xdj's avatar
      Streams: return an error message if using xreadgroup with '$' ID. · 6501b6bb
      dejun.xdj authored
      Redis will always return an empty result when '$' ID is specified
      with xreadgroup command, it's meaningless.
      6501b6bb
    • Oran Agra's avatar
      fix rare replication stream corruption with disk-based replication · d5559898
      Oran Agra authored
      The slave sends \n keepalive messages to the master while parsing the rdb,
      and later sends REPLCONF ACK once a second. rarely, the master recives both
      a linefeed char and a REPLCONF in the same read, \n*3\r\n$8\r\nREPLCONF\r\n...
      and it tries to trim two chars (\r\n) from the query buffer,
      trimming the '*' from *3\r\n$8\r\nREPLCONF\r\n...
      
      then the master tries to process a command starting with '3' and replies to
      the slave a bunch of -ERR and one +OK.
      although the slave silently ignores these (prints a log message), this corrupts
      the replication offset at the slave since the slave increases the replication
      offset, and the master did not.
      
      other than the fix in processInlineBuffer, i did several other improvments
      while hunting this very rare bug.
      
      - when redis replies with "unknown command" it includes a portion of the
        arguments, not just the command name. so it would be easier to understand
        what was recived, in my case, on the slave side,  it was -ERR, but
        the "arguments" were the interesting part (containing info on the error).
      - about a year ago i added code in addReplyErrorLength to print the error to
        the log in case of a reply to master (since this string isn't actually
        trasmitted to the master), now changed that block to print a similar log
        message to indicate an error being sent from the master to the slave.
        note that the slave is marked as CLIENT_SLAVE only after PSYNC was received,
        so this will not cause any harm for REPLCONF, and will only indicate problems
        that are gonna corrupt the replication stream anyway.
      - two places were c->reply was emptied, and i wanted to reset sentlen
        this is a precaution (i did not actually see such a problem), since a
        non-zero sentlen will cause corruption to be transmitted on the socket.
      d5559898
    • antirez's avatar
      dict.c: remove a few trailing spaces. · cefe21d2
      antirez authored
      cefe21d2
    • Salvatore Sanfilippo's avatar
      Merge pull request #5128 from kingpeterpaule/remove-one-loop-in-freeMemoryIfNeeded · 4fc20992
      Salvatore Sanfilippo authored
      remove ineffective loop in dictGetSomeKeys.
      4fc20992
  2. 16 Jul, 2018 15 commits
  3. 15 Jul, 2018 1 commit
  4. 14 Jul, 2018 3 commits
  5. 13 Jul, 2018 12 commits