Now the rdbSave* functions return the number of bytes written (or
required to write) in serializing a Redis object, writing to /dev/null
and using ftell (which doesn't work on FreeBSD) isn't needed anymore.

volatile-lru maxmemory policy segfault fixed, thanks to Anthony Lauzon for reporting the problem with the patch. Original patch modified a bit in order to avoid the double lookup if the policy is allkeys-lru

added noeviction policy to redis maxmemory. ZSCORE removed from the list of commands that can't be called when we are low on memory, this command was added in the past for a stupid error.

first attempt to non blocking implementation of slave replication and SYNC bulk data download. Never compiled so far...

Revert "Function to compute RSS memory usage in a fast way, suitable to be called inside keys eviction loops"

This reverts commit 7d47ecd5.

Revert "Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory."

This reverts commit a3e60027.

Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory.

Function to compute RSS memory usage in a fast way, suitable to be called inside keys eviction loops

Make sure to reset the signal handler and deliver again the original crashing signal when dumping the stack trace. This will allow to dump the core if core dumping is enabled.

Object approximated LRU algorithm enhanced / fixed / refactored. This is used for the VM currently but will soon be used for maxmemory expiring.

maxmemory fixed, we now try to release memory just before we check for the memory limit. Before fixing there was code between the attempt to free memory and the check for memory limits, and this code could result into allocations going again after the memory limit.

This should fix Issue 332: when there is a background process saving we still allow the hash tables to grow, but only when a critical treshold is reached. Formerly we prevented the resize at all triggering pathological O(N) behavior. Also there is a fix for the statistics in INFO about the number of keys expired