stevomitric opened a new pull request, #58774:
URL: https://github.com/apache/spark/pull/58774

   
   ### What changes were proposed in this pull request?
   `UnsafeWriter.write(int, CalendarInterval)` reserves a 16-byte 
variable-length payload for every value, but its null branch only sets the null 
bit and leaves those bytes untouched. This PR zeroes the reserved payload in 
the null branch, mirroring the in-place update path `UnsafeRow#setInterval`, 
which already zeroes it the same way.
   
   
   ### Why are the changes needed?
   Because the projection output buffer is reused across rows, a null interval 
inherits the stale bytes of a previous non-null row, so two logically-equal 
null values can encode to different `UnsafeRow` bytes. A nullable 
`CalendarInterval` used as a hash GROUP BY or join key can therefore split its 
NULLs across several groups. This is a latent correctness defect found by code 
inspection (the sibling of the same issue in the nanosecond-timestamp writer); 
there is no demonstrated query-level repro, but null-key byte identity is a 
correctness invariant.
   
   
   ### Does this PR introduce _any_ user-facing change?
   No.
   
   
   ### How was this patch tested?
   New `UnsafeRowConverterSuite` test "null interval keys are byte-identical 
regardless of prior rows" projects a null after two different non-null 
intervals and asserts the two null rows are byte-identical. It fails without 
the fix (both codegen and interpreted modes) and passes with it.
   
   
   ### Was this patch authored or co-authored using generative AI tooling?
   Co-Authored-By: Claude Opus 4.8
   


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