zclllyybb commented on issue #65800:
URL: https://github.com/apache/doris/issues/65800#issuecomment-5018359152

   Breakwater-GitHub-Analysis-Slot: slot_7ebce944bc43
   This content is generated by AI for reference only.
   
   Initial code-level analysis:
   
   The report looks valid against current `upstream/master` 
(`91a12e13170268812c0002e653b408eca002ca3f`). The `MIN_DELTA` transition itself 
already classifies `UPDATE -> DELETE` as a single `DELETE` in 
`be/src/storage/iterator/binlog_block_reader_utils.h`, so the likely problem is 
not the transition matrix.
   
   The suspicious part is row materialization in 
`BlockReader::_min_delta_next_block()` 
(`be/src/storage/iterator/block_reader.cpp`). In the `ResultType::DELETE` 
branch, the output operation is correctly changed to `STREAM_CHANGE_DELETE`, 
but all non-op payload columns are copied from `_stored_data_columns[idx]` at 
`group_size - 1`, i.e. from the last row in the same-key change group. For the 
sequence in this issue, that last row is the physical DELETE row after the 
update, so the emitted value becomes `11`.
   
   For `MIN_DELTA` semantics, a folded `DELETE` should describe removal of the 
row that existed at the stream window start. In the `UPDATE -> DELETE` case, 
that value is available from the first UPDATE row's `__BEFORE__` columns, not 
from the later DELETE row. This also matches the FE time-travel/table-stream 
comments in `BindRelation.java`, which assume `UPDATE_BEFORE` and `DELETE` rows 
carry the before image.
   
   One more useful signal: current regression coverage appears to encode the 
same wrong behavior. 
`regression-test/suites/table_stream_p0/test_min_delta_stream.groovy` has an 
`UPDATE then DELETE` case and currently asserts the updated value (`101`) for 
the folded DELETE, while its comment says the value should use the before 
snapshot. That test should be corrected to assert the pre-window value.
   
   Suggested next steps:
   
   1. Fix the `ResultType::DELETE` materialization path in 
`BlockReader::_min_delta_next_block()` so value columns for an `UPDATE -> 
DELETE` group are read from the first row's before-image columns. Keep the 
stream sequence/binlog metadata behavior reviewed separately, because consumers 
may still expect the folded event to advance to the latest operation in the 
group.
   2. Update/add regression coverage with the exact case from this issue: 
initial `(1, 10)`, then update to `11`, then delete, and assert `DELETE(10)`.
   3. Review the adjacent folded-delete cases (`DELETE -> DELETE`, multi-update 
followed by delete, cross-rowset same-key grouping) so pure delete still emits 
the deleted row value and update-delete emits the original pre-window value.
   
   No runtime profile is needed for this report. The only missing public 
metadata is the exact Doris build/commit where the reporter reproduced it, but 
the issue is already reproducible from current upstream code inspection.
   


-- 
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]

Reply via email to