Uh oh!
There was an error while loading. Please reload this page.
[fix](row binlog): op should be insert but update when insert after delete - #66046
Conversation
hello-stephen
commented
Jul 25, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Userwhite
commented
Jul 25, 2026
/review |
Userwhite
commented
Jul 25, 2026
run buildall |
hello-stephen
commented
Jul 25, 2026
TPC-H: Total hot run time: 29756 ms |
hello-stephen
commented
Jul 25, 2026
TPC-DS: Total hot run time: 177500 ms |
hello-stephen
commented
Jul 25, 2026
ClickBench: Total hot run time: 25.02 s |
hello-stephen
commented
Jul 25, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Userwhite
commented
Jul 28, 2026
run buildall |
hello-stephen
commented
Jul 28, 2026
TPC-H: Total hot run time: 29718 ms |
hello-stephen
commented
Jul 28, 2026
TPC-DS: Total hot run time: 177639 ms |
hello-stephen
commented
Jul 28, 2026
ClickBench: Total hot run time: 25.05 s |
hello-stephen
commented
Jul 28, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
gavinchou
commented
Jul 31, 2026
/review |
Codex automated review failed and did not complete. Error: You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at Aug 5th, 2026 4:32 AM. Please inspect the workflow logs and rerun the review after the underlying issue is resolved. |
PR approved by at least one committer and no changes requested. |
hello-stephen
commented
Jul 31, 2026
skip buildall |
Uh oh!
There was an error while loading. Please reload this page.
…elete (apache#66046) ### What problem does this PR solve? Issue Number: closeapache#65808 The main reason for the OP error is that the data has already been deleted, but in Doris, deletion may only set the delete sign to 1, so the data can still be queried when retrieving historical data. Therefore, we need to proactively detect this situation. --------- Co-authored-by: Gavin Chou <gavineaglechou@gmail.com>
…RowBinlogSegmentWriter Last PR of the block-transform-chain stack. RowBinlogDeriveStage rebuilds the load block into a full-width block over the binlog schema -- key + AFTER values, optional __BEFORE__* values, and the TSO/LSN/op columns -- so the ordinary segment writers write it like any other block. build_transform_chain picks PlainRowBinlogDerive (no history probe) or MowRowBinlogDerive (partial update and/or BEFORE image) per flush, and keeps an empty chain for every non-direct write type, whose rows are already binlog shaped. RowBinlogSegmentWriter is deleted, and with it the dead VerticalRowBinlogRowsetWriter template, the retriever's clear() bridge and SegmentWriter::build_key_index's protected visibility. SegmentFlusher no longer special-cases binlog when it picks a writer. Three later fixes to the deleted writer are carried into the stage, since deleting the file would drop them silently: - apache#66046: the op revision from the old delete sign runs between the BEFORE fill and the op column fill, the order the writer used. - apache#65810: the cloud-mode rejection is gone, and the historical lookup uses source.base_tablet. The writer fell back to its own tablet when that was unset; the stage requires it instead, because on a binlog write the writer context's tablet is the binlog tablet, which holds no source rows. Every site that fills source.tablet_schema fills source.base_tablet too. - apache#66553: AFTER value columns are wrapped nullable before they land in the binlog block, which declares them nullable. Behavior change to ack: binlog segments are written by the ordinary segment writer, which is the vertical one under the default enable_vertical_segment_writer=true; the deleted writer was always horizontal. The derived rows are identical -- the plain, MoW and BEFORE binlog goldens recorded through the vertical writer are byte-identical to the baselines recorded from the legacy writer -- but the writer type and the physical page layout are visible to operational tooling. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
What problem does this PR solve?
Issue Number: close#65808
The main reason for the OP error is that the data has already been deleted, but in Doris, deletion may only set the delete sign to 1, so the data can still be queried when retrieving historical data.
Therefore, we need to proactively detect this situation.
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)