zclllyybb commented on issue #65705:
URL: https://github.com/apache/doris/issues/65705#issuecomment-4990161640
Breakwater-GitHub-Analysis-Slot: slot_c897704dfc83
This content is generated by AI for reference only.
Initial assessment:
This should be treated as a real table-stream `INSERT SELECT` product bug,
not as a Routine Load issue, target-table delete-sign issue, or regression
assertion issue.
The strongest evidence is the reduced SQL in the issue: after the base-table
`DELETE`, a direct `SELECT` from the `MIN_DELTA` stream can see the two
`DELETE` rows, but the following `INSERT INTO audit SELECT ... FROM s WHERE
__DORIS_STREAM_CHANGE_TYPE_COL__ IN (...)` inserts zero rows. The large stress
case also reports that the stream lag advances to zero while the downstream
target remains unchanged.
Code-backed notes from current `upstream/master` inspection:
1. FE stream normalization maps row-binlog operations to the stream virtual
change-type column in `NormalizeOlapTableStreamScan`: normal incremental stream
reads are rewritten to a `RowBinlogTableWrapper` scan with
`TableScanParams.INCREMENTAL_READ` and `MIN_DELTA`, then
`__DORIS_STREAM_CHANGE_TYPE_COL__` is synthesized from the binlog op. This
matches the direct `SELECT FROM s` visibility reported in the issue.
2. BE `BlockReader::_min_delta_next_block()` has an explicit `DELETE` result
branch that emits a row with `STREAM_CHANGE_DELETE`. That also supports the
issue author's observation that the stream scan can materialize DELETE rows.
3. For `INSERT SELECT`, `InsertIntoTableCommand` extracts
`TableStreamUpdateInfo` from the analyzed stream scan and attaches it to the
transaction before execution. The offset update is based on the planned stream
window, not on the number of rows that finally reach the target sink. This
explains the dangerous split reported here: lag can be consumed to zero even if
the target receives zero rows.
4. Existing upstream table-stream regression coverage already has a mixed
`MIN_DELTA` batch where `INSERT INTO target SELECT ... FROM stream` inserts a
`DELETE` change row into a duplicate-key audit table. The new gap is more
specific: a DELETE-only incremental window, with a change-type
filter/projection, consumed through `INSERT SELECT`.
Most likely boundary:
The narrow suspect is the stream `INSERT SELECT` plan/execution path when
the current incremental window contains only `DELETE` events and the query
filters or projects `__DORIS_STREAM_CHANGE_TYPE_COL__`. The issue is less
likely to be target MOW delete-sign handling, because the reduced duplicate-key
`audit` table also receives zero rows, and the issue already checked direct
`__DORIS_DELETE_SIGN__` writes separately.
This does not look like a duplicate of #65339: that issue is a BE crash
while selecting stream change-type rows, while this issue has a successful
direct stream SELECT but loses rows during `INSERT SELECT` consumption.
Missing information needed to pin the exact failing line:
1. The exact FE and BE build commit IDs for the failing cluster. The issue
currently says the build version was not printed.
2. `EXPLAIN VERBOSE` for both of these statements after the DELETE-only
window is present:
- `SELECT id, version_no, payload, __DORIS_STREAM_CHANGE_TYPE_COL__ FROM
s WHERE __DORIS_STREAM_CHANGE_TYPE_COL__ IN
('APPEND','INSERT','UPDATE_AFTER','DELETE')`
- the corresponding `INSERT INTO ... SELECT ... FROM s WHERE ...`
3. A query profile for the failing `INSERT SELECT`, especially scan rows
returned, rows after filter/project, and rows sent to the sink. This will
distinguish "scan produced zero rows under insert context" from "scan produced
DELETE rows but filter/project/sink dropped them."
4. A small variant of the reduced SQL that runs `INSERT INTO audit SELECT
id, version_no, payload, __DORIS_STREAM_CHANGE_TYPE_COL__ FROM s` without the
`WHERE` predicate, to isolate whether the change-type filter is required for
the loss.
5. Stream lag/status before and after the failing `INSERT SELECT`, with the
query id, so the offset update can be correlated to the zero inserted rows.
Suggested next steps:
1. Add a regression under `table_stream_p0` for a DELETE-only `MIN_DELTA`
incremental window after prior APPEND/UPDATE consumption. The test should
assert that the same filtered SELECT returns DELETE rows, that `INSERT INTO
duplicate audit SELECT ... WHERE change_type IN (...)` inserts those DELETE
rows, and that writing `__DORIS_DELETE_SIGN__ = 1` into a MOW target reduces
the target row count.
2. Compare the normalized plan for standalone SELECT versus `INSERT SELECT`.
If the standalone filtered SELECT returns DELETE rows but the insert plan does
not, focus on stream-scan normalization, partition pruning, predicate pushdown
through the synthesized change-type projection, and insert-target planning.
3. If the BE scan profile shows DELETE rows are produced but the sink
receives zero rows, focus on the projection/filter/sink boundary rather than
the MIN_DELTA reader itself.
--
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]
