yuqi1129 commented on PR #12454: URL: https://github.com/apache/gravitino/pull/12454#issuecomment-5277731972
Thanks for the review. Responses to the three Copilot comments: **1. `metalakeWriteFailure()` uses a locking read** — keeping the locking read, but I have documented why in the code. The lock is load-bearing for correctness, not incidental. Under MySQL REPEATABLE READ a plain `SELECT` returns this transaction's snapshot, which still shows a row that a concurrent writer has already deleted or renamed away. That makes "stale version" and "already gone" indistinguishable, and a drop that lost the race would report a 409 conflict instead of staying idempotent. A locking read observes the latest committed row. It also does not add waiting in practice: the compare-and-set is an `UPDATE`, so it has already queued on that same row lock. By the time this classification path runs, the competing writer has committed. **2 & 3. Row-value `IN` instead of the OR-chain in the CAS delete** — not taking this for now. - The pattern applies equally to the MySQL/H2 base provider, so adopting it only in the PostgreSQL provider would fragment the dialects for an unmeasured gain. - It does not address the real scaling limit. Both forms bind two parameters per row, so a sufficiently wide cascade hits PostgreSQL's 65535 bind-parameter ceiling either way. If cascade width becomes a concern, the fix is to chunk the delete, which belongs in a separate change with a benchmark behind it. Pushed the clarifying comment for (1); the same note is applied to the equivalent paths in #12455 and #12456. -- 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]
