gvsafronov/futriix
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity

Update comment around propagateDeletion (#12687)

Browse Source 
Fix some outdated comments and add comment for moduleNotifyKeyspaceEvent
we added in #11084 since it seems a bit implicit.

---------

Co-authored-by: Oran Agra <oran@redislabs.com>
This commit is contained in:
Binbin 2023-10-24 05:10:03 -05:00 committed by GitHub
parent 3fac869f02
commit 372ea21875
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 13 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/cluster.c
View File

@ -7558,6 +7558,9 @@ unsigned int delKeysInSlot(unsigned int hashslot) {
dbDelete(&server.db[0], key);
propagateDeletion(&server.db[0], key, server.lazyfree_lazy_server_del);
signalModifiedKey(NULL, &server.db[0], key);
/* The keys are not actually logically deleted from the database, just moved to another node.
* The modules needs to know that these keys are no longer available locally, so just send the
* keyspace notification to the modules, but not to clients. */
moduleNotifyKeyspaceEvent(NOTIFY_GENERIC, "del", key, server.db[0].id);
postExecutionUnitOperations();
decrRefCount(key);

19
src/db.c
View File

@ -2012,23 +2012,24 @@ void deleteExpiredKeyAndPropagate(redisDb *db, robj *keyobj) {
server.stat_expiredkeys++;
}
/* Propagate expires into slaves and the AOF file.
* When a key expires in the master, a DEL operation for this key is sent
* to all the slaves and the AOF file if enabled.
/* Propagate an implicit key deletion into replicas and the AOF file.
* When a key was deleted in the master by eviction, expiration or a similar
* mechanism a DEL/UNLINK operation for this key is sent
* to all the replicas and the AOF file if enabled.
*
* This way the key expiry is centralized in one place, and since both
* AOF and the master->slave link guarantee operation ordering, everything
* will be consistent even if we allow write operations against expiring
* This way the key deletion is centralized in one place, and since both
* AOF and the replication link guarantee operation ordering, everything
* will be consistent even if we allow write operations against deleted
* keys.
*
* This function may be called from:
* 1. Within call(): Example: Lazy-expire on key access.
* In this case the caller doesn't have to do anything
* because call() handles server.also_propagate(); or
* 2. Outside of call(): Example: Active-expire, eviction.
* 2. Outside of call(): Example: Active-expire, eviction, slot ownership changed.
* In this the caller must remember to call
* postExecutionUnitOperations, preferably just after a
* single deletion batch, so that DELs will NOT be wrapped
* single deletion batch, so that DEL/UNLINK will NOT be wrapped
* in MULTI/EXEC */
void propagateDeletion(redisDb *db, robj *key, int lazy) {
robj *argv[2];
@ -2038,7 +2039,7 @@ void propagateDeletion(redisDb *db, robj *key, int lazy) {
incrRefCount(argv[0]);
incrRefCount(argv[1]);
/* If the master decided to expire a key we must propagate it to replicas no matter what..
/* If the master decided to delete a key we must propagate it to replicas no matter what.
* Even if module executed a command without asking for propagation. */
int prev_replication_allowed = server.replication_allowed;
server.replication_allowed = 1;