1. 26 Jun, 2014 1 commit
    • antirez's avatar
      Test: hopefully more robust PSYNC test. · e7887e60
      antirez authored
      This is supposed to fix issue #1417, but we'll know if this is enough
      only after a couple of runs of the CI test without false positives.
      e7887e60
  2. 23 Jun, 2014 2 commits
    • antirez's avatar
      Sentinel test: more correct sentinels config reset. · e21e0ba3
      antirez authored
      In the initialization test for each instance we used to unregister the
      old master and register it again to clear the config.
      However there is a race condition doing this: as soon as we unregister
      and re-register "mymaster", another Sentinel can update the new
      configuration with the old state because of gossip "hello" messages.
      
      So the correct procedure is instead, unregister "mymaster" from all the
      sentinel instances, and re-register it everywhere again.
      e21e0ba3
    • antirez's avatar
      Basic tests for the ROLE command. · 1206bdf1
      antirez authored
      1206bdf1
  3. 19 Jun, 2014 3 commits
  4. 18 Jun, 2014 5 commits
  5. 12 Jun, 2014 2 commits
    • antirez's avatar
      Scripting: regression test for issue #1811. · aa19fd61
      antirez authored
      aa19fd61
    • antirez's avatar
      Fix semantics of Lua calls to SELECT. · 96e0fe62
      antirez authored
      Lua scripts are executed in the context of the currently selected
      database (as selected by the caller of the script).
      
      However Lua scripts are also free to use the SELECT command in order to
      affect other DBs. When SELECT is called frm Lua, the old behavior, before
      this commit, was to automatically set the Lua caller selected DB to the
      last DB selected by Lua. See for example the following sequence of
      commands:
      
          SELECT 0
          SET x 10
          EVAL "redis.call('select','1')" 0
          SET x 20
      
      Before this commit after the execution of this sequence of commands,
      we'll have x=10 in DB 0, and x=20 in DB 1.
      
      Because of the problem above, there was a bug affecting replication of
      Lua scripts, because of the actual implementation of replication. It was
      possible to fix the implementation of Lua scripts in order to fix the
      issue, but looking closely, the bug is the consequence of the behavior
      of Lua ability to set the caller's DB.
      
      Under the old semantics, a script selecting a different DB, has no simple
      ways to restore the state and select back the previously selected DB.
      Moreover the script auhtor must remember that the restore is needed,
      otherwise the new commands executed by the caller, will be executed in
      the context of a different DB.
      
      So this commit fixes both the replication issue, and this hard-to-use
      semantics, by removing the ability of Lua, after the script execution,
      to force the caller to switch to the DB selected by the Lua script.
      
      The new behavior of the previous sequence of commadns is to just set
      X=20 in DB 0. However Lua scripts are still capable of writing / reading
      from different DBs if needed.
      
      WARNING: This is a semantical change that will break programs that are
      conceived to select the client selected DB via Lua scripts.
      
      This fixes issue #1811.
      96e0fe62
  6. 11 Jun, 2014 2 commits
  7. 10 Jun, 2014 9 commits
  8. 05 Jun, 2014 1 commit
  9. 04 Jun, 2014 1 commit
  10. 26 May, 2014 2 commits
  11. 23 May, 2014 4 commits
  12. 22 May, 2014 2 commits
  13. 21 May, 2014 1 commit
    • Matt Stancliff's avatar
      Fix blocking operations from missing new lists · 33f943b4
      Matt Stancliff authored
      Behrad Zari discovered [1] and Josiah reported [2]: if you block
      and wait for a list to exist, but the list creates from
      a non-push command, the blocked client never gets notified.
      
      This commit adds notification of blocked clients into
      the DB layer and away from individual commands.
      
      Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE,
      and RESTORE.  Previously, blocked client notifications were
      only triggered by [LR]PUSH.  Your client would never get
      notified if a list were created by SORT..STORE or RENAME or
      a RESTORE, etc.
      
      Blocked client notification now happens in one unified place:
        - dbAdd() triggers notification when adding a list to the DB
      
      Two new tests are added that fail prior to this commit.
      
      All test pass.
      
      Fixes #1668
      
      [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU
      [2]: #1668
      33f943b4
  14. 20 May, 2014 1 commit
  15. 19 May, 2014 4 commits