Commits on Jul 24, 2017
  1. Merge pull request #1934 from badboy/install-script-1922

    Don't use extended Regexp Syntax
    committed on GitHub Jul 24, 2017
  2. Merge pull request #2259 from badboy/fix-2258

    Check that the whole first argument is a number
    committed on GitHub Jul 24, 2017
  3. Merge pull request #4124 from lamby/proceding-proceeding-typo

    Correct proceding -> proceeding typo.
    committed on GitHub Jul 24, 2017
  4. Merge pull request #4125 from trevor211/fixAutoAofRewirteMinSize

    fix rewrite config: auto-aof-rewrite-min-size
    committed on GitHub Jul 24, 2017
  5. Merge pull request #1998 from grobe0ba/unstable

    Fix missing '-' in redis-benchmark help output (Issue #1996)
    committed on GitHub Jul 24, 2017
  6. Merge pull request #4128 from leonchen83/unstable

    fix mismatch argument and return wrong value of clusterDelNodeSlots
    committed on GitHub Jul 24, 2017
  7. Merge pull request #4154 from liangsijian/unstable

    Fix lua ldb command log
    committed on GitHub Jul 24, 2017
Commits on Jul 23, 2017
  1. Modules: don't crash when Lua calls a module blocking command.

    Lua scripting does not support calling blocking commands, however all
    the native Redis commands are flagged as "s" (no scripting flag), so
    this is not possible at all. With modules there is no such mechanism in
    order to flag a command as non callable by the Lua scripting engine,
    moreover we cannot trust the modules users from complying all the times:
    it is likely that modules will be released to have blocking commands
    without such commands being flagged correctly, even if we provide a way to
    signal this fact.
    This commit attempts to address the problem in a short term way, by
    detecting that a module is trying to block in the context of the Lua
    scripting engine client, and preventing to do this. The module will
    actually believe to block as usually, but what happens is that the Lua
    script receives an error immediately, and the background call is ignored
    by the Redis engine (if not for the cleanup callbacks, once it
    Long term, the more likely solution, is to introduce a new call called
    RedisModule_GetClientFlags(), so that a command can detect if the caller
    is a Lua script, and return an error, or avoid blocking at all.
    Being the blocking API experimental right now, more work is needed in
    this regard in order to reach a level well blocking module commands and
    all the other Redis subsystems interact peacefully.
    Now the effect is like the following:
   > eval "'hello.block',1,5000)" 0
        (error) ERR Error running script (call to
        f_b5ba35ff97bc1ef23debc4d6e9fd802da187ed53): @user_script:1: ERR
        Blocking module command called from Lua script
    This commit fixes issue #4127 in the short term.
    committed Jul 23, 2017
Commits on Jul 20, 2017
  1. Make representClusterNodeFlags() more robust.

    This function failed when an internal-only flag was set as an only flag
    in a node: the string was trimmed expecting a final comma before
    exiting the function, causing a crash. See issue #4142.
    Moreover generation of flags representation only needed at DEBUG log
    level was always performed: a waste of CPU time. This is fixed as well
    by this commit.
    committed Jul 20, 2017
  2. Fix two bugs in moduleTypeLookupModuleByID().

    The function cache was not working at all, and the function returned
    wrong values if there where two or more modules exporting native data
    See issue #4131 for more details.
    committed Jul 20, 2017
Commits on Jul 14, 2017
  1. changelog.tcl: output 100 lines.

    committed Jul 14, 2017
  2. Modules: fix thread safe context DB selection.

    Before this fix the DB currenty selected by the client blocked was not
    respected and operations were always performed on DB 0.
    committed Jul 14, 2017
  3. Allow certain modules APIs only defining REDISMODULE_EXPERIMENTAL_API.

    Those calls may be subject to changes in the future, so the user should
    acknowledge it is using non stable API.
    committed Jul 14, 2017
  4. Modules documentation removed from source.

    Moving to redis-doc repository to publish via
    committed Jul 14, 2017
Commits on Jul 12, 2017
  1. Fix replication of SLAVEOF inside transaction.

    In Redis 4.0 replication, with the introduction of PSYNC2, masters and
    slaves replicate commands to cascading slaves and to the replication
    backlog itself in a different way compared to the past.
    Masters actually replicate the effects of client commands.
    Slaves just propagate what they receive from masters.
    This mechanism can cause problems when the configuration of an instance
    is changed from master to slave inside a transaction. For instance
    we could send to a master instance the following sequence:
        SLAVEOF 0
    Before the fixes in this commit, the MULTI command used to be propagated
    into the replication backlog, however after the SLAVEOF command the
    instance is a slave, so the EXEC implementation failed to also propagate
    the EXEC command. When the slaves of the above instance reconnected,
    they were incrementally synchronized just sending a "MULTI". This put
    the master client (in the slaves) into MULTI state, breaking the
    Notably even Redis Sentinel uses the above approach in order to guarantee
    that configuration changes are always performed together with rewrites
    of the configuration and with clients disconnection. Sentiel does:
        SLAVEOF ...
        CLIENT KILL TYPE normal
    So this was a really problematic issue. However even with the fix in
    this commit, that will add the final EXEC to the replication stream in
    case the instance was switched from master to slave during the
    transaction, the result would be to increment the slave replication
    offset, so a successive reconnection with the new master, will not
    permit a successful partial resynchronization: no way the new master can
    provide us with the backlog needed, we incremented our offset to a value
    that the new master cannot have.
    However the EXEC implementation waits to emit the MULTI, so that if the
    commands inside the transaction actually do not need to be replicated,
    no commands propagation happens at all. From multi.c:
        if (!must_propagate && !(c->cmd->flags & (CMD_READONLY|CMD_ADMIN))) {
    	must_propagate = 1;
    The above code is already modified by this commit you are reading.
    Now also ADMIN commands do not trigger the emission of MULTI. It is actually
    not clear why we do not just check for CMD_WRITE... Probably I wrote it this
    way in order to make the code more reliable: better to over-emit MULTI
    than not emitting it in time.
    So this commit should indeed fix issue #3836 (verified), however it looks
    like some reconsideration of this code path is needed in the long term.
    BONUS POINT: The reverse bug.
    Even in a read only slave "B", in a replication setup like:
    	A -> B -> C
    There are commands without the READONLY nor the ADMIN flag, that are also
    not flagged as WRITE commands. An example is just the PING command.
    So if we send B the following sequence:
    The result will be the reverse bug, where only EXEC is emitted, but not the
    previous MULTI. However this apparently does not create problems in practice
    but it is yet another acknowledge of the fact some work is needed here
    in order to make this code path less surprising.
    Note that there are many different approaches we could follow. For instance
    MULTI/EXEC blocks containing administrative commands may be allowed ONLY
    if all the commands are administrative ones, otherwise they could be
    denined. When allowed, the commands could simply never be replicated at all.
    committed Jul 12, 2017
Commits on Jul 11, 2017
  1. CLUSTER GETKEYSINSLOT: avoid overallocating.

    Close #3911.
    committed Jul 11, 2017
  2. Clients blocked in modules: free argv/argc later.

    See issue #3844 for more information.
    committed Jul 11, 2017
Commits on Jul 10, 2017
  1. Event loop: call after sleep() only from top level.

    In general we do not want before/after sleep() callbacks to be called
    when we re-enter the event loop, since those calls are only designed in
    order to perform operations every main iteration of the event loop, and
    re-entering is often just a way to incrementally serve clietns with
    error messages or other auxiliary operations. However, if we call the
    callbacks, we are then forced to think at before/after sleep callbacks
    as re-entrant, which is much harder without any good need.
    However here there was also a clear bug: beforeSleep() was actually
    never called when re-entering the event loop. But the new afterSleep()
    callback was. This is broken and in this instance re-entering
    afterSleep() caused a modules GIL dead lock.
    committed Jul 10, 2017
  2. Merge pull request #4113 from guybe7/module_io_bytes

    Modules: Fix io->bytes calculation in RDB save
    committed on GitHub Jul 10, 2017
Commits on Jul 6, 2017
  1. Merge pull request #3853 from itamarhaber/issue-3851

    Sets up fake client to select current db in RM_Call()
    committed on GitHub Jul 6, 2017
  2. Merge pull request #4105 from spinlock/unstable-networking

    Optimize addReplyBulkSds for better performance
    committed on GitHub Jul 6, 2017
  3. Merge pull request #4106 from petersunbag/unstable

    minor fix in listJoin().
    committed on GitHub Jul 6, 2017
  4. Free IO context if any in RDB loading code.

    Thanks to @oranagra for spotting this bug.
    committed Jul 6, 2017
Commits on Jul 5, 2017
  1. Modules: no MULTI/EXEC for commands replicated from async contexts.

    They are technically like commands executed from external clients one
    after the other, and do not constitute a single atomic entity.
    committed Jul 5, 2017
Commits on Jul 4, 2017
  1. Merge pull request #4101 from dvirsky/fix_modules_reply_len

    Proposed fix to #4100
    committed on GitHub Jul 4, 2017
  2. Add symmetrical assertion to track c->reply_buffer infinite growth.

    Redis clients need to have an instantaneous idea of the amount of memory
    they are consuming (if the number is not exact should at least be
    proportional to the actual memory usage). We do that adding and
    subtracting the SDS length when pushing / popping from the client->reply
    list. However it is quite simple to add bugs in such a setup, by not
    taking the objects in the list and the count in sync. For such reason,
    Redis has an assertion to track counts near 2^64: those are always the
    result of the counter wrapping around because we subtract more than we
    add. This commit adds the symmetrical assertion: when the list is empty
    since we sent everything, the reply_bytes count should be zero. Thanks
    to the new assertion it should be simple to also detect the other
    problem, where the count slowly increases because of over-counting.
    The assertion adds a conditional in the code that sends the buffer to
    the socket but should not create any measurable performance slowdown,
    listLength() just accesses a structure field, and this code path is
    totally dominated by write(2).
    Related to #4100.
    committed Jul 4, 2017
Commits on Jul 3, 2017
  1. Fix GEORADIUS edge case with huge radius.

    This commit closes issue #3698, at least for now, since the root cause
    was not fixed: the bounding box function, for huge radiuses, does not
    return a correct bounding box, there are points still within the radius
    that are left outside.
    So when using GEORADIUS queries with radiuses in the order of 5000 km or
    more, it was possible to see, at the edge of the area, certain points
    not correctly reported.
    Because the bounding box for now was used just as an optimization, and
    such huge radiuses are not common, for now the optimization is just
    switched off when the radius is near such magnitude.
    Three test cases found by the Continuous Integration test were added, so
    that we can easily trigger the bug again, both for regression testing
    and in order to properly fix it as some point in the future.
    committed Jul 3, 2017