JunRuiLee commented on PR #771:
URL: https://github.com/apache/paimon-rust/pull/771#issuecomment-5614855322
Rebased onto #801, #802 and #803, now that all three are merged. 30 files /
+2,271−343.
One thing worth recording, because it changes how one of them should be
read: **#802 was load-bearing for this PR's trust boundary, not an independent
hardening fix.**
A bucket split names its own deletion files, so the deletion positions come
off the same untrusted bytes as everything else in the plan:
```
BucketVectorSearchSplit -> embedded DataSplit.data_deletion_files()
-> build_split_dv_factory(&split.data_split) pk_vector_orchestrator.rs
-> DeletionVectorFactory::new(io, data_files, data_deletion_files)
-> positions -> build_live_row_ids -> global = file_offset + position
```
Without #802's bound, a position past its own file lands in the **next**
file's ordinal range and drops one of that file's rows — silently, because the
mask stays well formed. Had this PR merged first, that would have been
reachable from a forged split. It read as one of three unrelated fixes and one
of them was not; it is on main now, so this branch inherits it.
Also new: `an_empty_index_outranks_a_filter_too_large_to_densify`, covering
where this PR's dense-filter byte budget meets #803's step order. Neither pins
it alone — without the ordering the budget rejects the query, without the
budget there is nothing to order against — so it could only be written after
#803 landed.
This branch also uses #801's `take_only_result` for its own single-query
unwrap rather than repeating the check inline.
--
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]
