You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Mark Jarvin (Jira)" <ji...@apache.org> on 2026/10/01 23:24:00 UTC

[jira] [Created] (SPARK-59941) Widen UnsafeExternalSorter row accounting to Long for window partitions larger than Int.MaxValue rows

Mark Jarvin created SPARK-59941:
-----------------------------------

             Summary: Widen UnsafeExternalSorter row accounting to Long for window partitions larger than Int.MaxValue rows
                 Key: SPARK-59941
                 URL: https://issues.apache.org/jira/browse/SPARK-59941
             Project: Spark
          Issue Type: Improvement
          Components: Spark Core
    Affects Versions: 5.0.0
            Reporter: Mark Jarvin


h2. Summary

{{org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter}} accounts for buffered rows
in 32-bit {{int}}s on the read path:

* {{UnsafeSorterSpillWriter.recordsSpilled()}} returns {{int}}.
* {{UnsafeSorterIterator.getNumRecords()}} returns {{int}}.
* {{UnsafeInMemorySorter.numRecords()}} returns {{int}}.
* {{getIterator(int startIndex)}} accumulates spilled counts into an {{int i}} and skips a spill
  file unless {{i + spillWriter.recordsSpilled() > startIndex}}; {{ChainedIterator.numRecords}} is
  also {{int}}.

When a single buffered partition exceeds {{Int.MaxValue}} rows and has spilled, the running {{int}}
total overflows negative. Later spill files are then skipped (rows silently dropped), or
{{moveOver}} throws a raw {{ArrayIndexOutOfBoundsException}}. This affects window execution even on
the {{getIterator(0)}} path used by LEAD/LAG and unbounded-offset {{nth_value}}.

h2. Context

Follow-up to SPARK-59929, which widened the window row counter
({{ExternalAppendOnlyUnsafeRowArray.numRows}}/{{length}}) to {{Long}} and added a fail-fast guard
({{WINDOW_FUNCTION_PARTITION_SIZE_EXCEEDS_LIMIT}}) that currently rejects *every* window frame over
a partition larger than {{Int.MaxValue}} rows. Those frames cannot be made correct over such
partitions until this sorter accounting is widened.

h2. Proposed work

Widen the sorter's row accounting to {{long}} (the {{getIterator}} accumulator and skip condition,
{{ChainedIterator.numRecords}}, and the {{recordsSpilled()}} / {{getNumRecords()}} /
{{numRecords()}} surface and their consumers), then relax the window guard so the offset frames
(LEAD/LAG, unbounded {{nth_value}}) produce correct results for partitions larger than
{{Int.MaxValue}} rows instead of failing.

Related: SPARK-59929, SPARK-51757.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org