summaryrefslogtreecommitdiff
path: root/deps/hiredis/hiredis.c
diff options
context:
space:
mode:
authorPieter Noordhuis <pcnoordhuis@gmail.com>2012-01-13 17:49:16 -0800
committerantirez <antirez@gmail.com>2012-02-16 17:21:13 +0100
commitcb598cdd59f48ffa1cb2f3d82d95b8b9eaee7195 (patch)
tree88702b214a7b66305555120caf454aec8561f023 /deps/hiredis/hiredis.c
parentd347348109c955ebf287aafea5d7b65cd4ec9014 (diff)
downloadredis-cb598cdd59f48ffa1cb2f3d82d95b8b9eaee7195.tar.gz
Don't expire keys when loading an RDB after a SYNC
The cron is responsible for expiring keys. When keys are expired at load time, it is possible that the snapshot of a master node gets modified. This can in turn lead to inconsistencies in the data set. A more concrete example of this behavior follows. A user reported a slave that would show an monotonically increase input buffer length, shortly after completing a SYNC. Also, `INFO` output showed a single blocked client, which could only be the master link. Investigation showed that indeed the `BRPOP` command was fed by the master. This command can only end up in the stream of write operations when it did NOT block, and effectively executed `RPOP`. However, when the key involved in the `BRPOP` is expired BEFORE the command is executed, the client executing it will block. The client in this case, is the master link.
Diffstat (limited to 'deps/hiredis/hiredis.c')
0 files changed, 0 insertions, 0 deletions