imbajin commented on code in PR #3164:
URL: https://github.com/apache/hugegraph/pull/3164#discussion_r4014467837
##########
hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/business/BusinessHandlerImpl.java:
##########
@@ -1415,10 +1438,42 @@ public boolean dbCompaction(String graphName, int id,
String tableName) {
log.info("Partition {} dbCompaction started", id);
if (tableName.isEmpty()) {
lock(path);
- setState(id, doing);
- log.info("Partition {}-{} got lock, dbCompaction
start", id, path);
- op.compactRange();
- setState(id, compactionDone);
+ ReentrantLock rangeLock =
Review Comment:
⚠️ Blocking: yes. This new lock acquisition is inside the
tableName.isEmpty() branch. For a PD DB_COMPACTION request with a concrete
tableName, the else path still invokes op.compactRange(tableName) without
compactionRangeLock, while SnapshotHandler.onSnapshotSave reserves that lock. A
table-specific RocksDB compaction can therefore overlap checkpoint creation and
recreate the incomplete/corrupt snapshot race. Please acquire the same bounded
range lock for both overloads, or explicitly prove table compaction cannot
overlap snapshot creation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
