del key

[opt-m]

FT.DROPINDEX index DD will delete key as well，but i found this delete process use del instead of unlink which cause redis block。

    DocTable *dt = &sp->docs;
    DOCTABLE_FOREACH(dt, Redis_DeleteKeyC(ctx, dmd->keyPtr));
---

int Redis_DeleteKey(RedisModuleCtx *ctx, RedisModuleString *s) {
  RedisModuleCallReply *rep = RedisModule_Call(ctx, "DEL", "s", s);
  RedisModule_Assert(RedisModule_CallReplyType(rep) == REDISMODULE_REPLY_INTEGER);
  long long res = RedisModule_CallReplyInteger(rep);
  RedisModule_FreeCallReply(rep);
  return res;
}

int Redis_DeleteKeyC(RedisModuleCtx *ctx, char *cstr) {
  RedisModuleCallReply *rep;
  if (!isCrdt) {
    rep = RedisModule_Call(ctx, "DEL", "c!", cstr);
  } else {
    rep = RedisModule_Call(ctx, "DEL", "c", cstr);
  }
  RedisModule_Assert(RedisModule_CallReplyType(rep) == REDISMODULE_REPLY_INTEGER);
  long long res = RedisModule_CallReplyInteger(rep);
  RedisModule_FreeCallReply(rep);
  return res;
}

1. Can it be adjusted to "UNLINK" ?
2. DOCTABLE_FOREACH will send large command to redis core , can it adjusted to batch call in async way?

[freecw]

meet the same issue. It seems that the root cause is that before master deletes key, it remove spec, so it will not involve index udpate. However, when master deletes key, del is replicated to slave whose spec is still there. So slave involves index update, which is slow. And slave drag down the whole process. Maybe we can do dropindex in slave and then master. It seems it works.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.