Skip to content

[Bug]: LEAD with INT64_MAX offset returns wrong rows due to integer overflow #25906

Description

@Ariznawlll

Description

LEAD returns values from earlier rows instead of NULL when its offset is INT64_MAX and the current row index is greater than zero.

On latest main (234a93f81ce52b4457c7595e455eca4bba3bc680), the window operator computes the source row as:

srcRow := j + int(offset)
if srcRow >= end {
    // append default or NULL
} else {
    localResult.UnionOne(srcVec, int64(srcRow), ...)
}

For offset = math.MaxInt64, j + int(offset) overflows when j > 0. The result becomes negative, bypasses the srcRow >= end check, and is passed to UnionOne. The vector access then silently reads earlier rows.

Reproduction

Equivalent SQL shape:

select id,
       lead(id, 9223372036854775807) over (order by id)
from t;

With input [10, 20, 30], the operator currently produces null bitmap [0] and physical values [0, 10, 20]: only row 0 is NULL, while rows 1 and 2 incorrectly read prior rows.

Expected behavior

An offset larger than the remaining partition length is out of range for every row, so every LEAD result must be NULL (or the provided default value).

Actual behavior

Rows after the first return data from earlier rows because of signed integer overflow.

Impact

This is silent query-result corruption for a valid BIGINT offset. It does not return an error or panic, so callers can consume incorrect analytical results without noticing.

Metadata

Metadata

Assignees

Labels

kind/bugSomething isn't workingneeds-triageNeeds evaluation before prioritization. Not yet decided whether to proceed

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions