HIVE-29598: Fix vectorized outer join wrong results due to stale scratch column values

[ryukobayashi]

What changes were proposed in this pull request?

In vectorized outer join, generateOuterNulls() and generateOuterNullsRepeatedAll() set isNull[i] = true on scratch columns but leave vector[i] untouched. When hive.vectorized.reuse.scratch.columns=true (the default), a scratch column slot
freed after an expression evaluation (e.g. CastStringToLong) can be reused for the outer join's null-marking column. After reset() clears isNull[], the expression overwrites vector[i] with a fresh value (e.g. 2025). Later, generateOuterNulls()
sets isNull[i] = true without clearing vector[i], leaving a stale non-zero value.

Downstream operators such as ColOrCol read vector[i] directly to distinguish "false" (== 0) from "null" (!= 0). The stale value causes null rows to be misinterpreted as "true", producing wrong OR/AND/CASE WHEN results.

The fix adds clearVectorValue(), called whenever isNull[i] is set to true in the outer join null-marking paths, zeroing vector[i] for all supported column vector types (LongColumnVector, DoubleColumnVector, BytesColumnVector,
TimestampColumnVector, IntervalDayTimeColumnVector).

Why are the changes needed?

Without the fix, vectorized outer joins silently return wrong results when scratch column reuse is enabled (the default). The bug is non-obvious because it only triggers when a specific combination of conditions is met: a type-casting expression allocates a scratch column that is later reused for the outer join's null-marking column, and the join result is consumed by a boolean operator that reads the raw vector value for null discrimination. Users have no indication that results are wrong; workarounds require disabling vectorization entirely (hive.vectorization.enabled=false) or disabling scratch column reuse (hive.vectorized.reuse.scratch.columns=false), both of which carry a significant performance cost.

Does this PR introduce any user-facing change?

No

How was this patch tested?

I added qtest.

[soumyakanti3578]

Vectorization code can be tricky and brittle. To ensure there are no unintended consequences of this change, could you please add some tests? A minimal reproducer as a qtest is essential, and unit tests for the vector clearing operation across different ColumnVector types would also be valuable.

[konstantinb]

@ryukobayashi could you please take a look at my suggestions to your approach: ryukobayashi#1 ?

The PR is a bit better reproducing the actual problem and incorporates multiple suggestions from @soumyakanti3578

[ryukobayashi]

@konstantinb Thanks, I accept your proposal because it makes sense.

[konstantinb]

@ryukobayashi one more tweak: ryukobayashi#2 which addresses SQ feedback and trims excessive comments/hive config flags the test uses.

The main module still seems to have at least three code paths unfixed, but those are, apparently, impossible to hit with current CBO rewrites. I am unsure if we should leave those as they are now or fix preemptively

[ryukobayashi]

@konstantinb Merged. If the corrections are minor, I think it's okay to do them just to be safe.

[konstantinb]

Added suggestions to address SonarQube feedback

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.5% Duplication on New Code

See analysis details on SonarQube Cloud

[soumyakanti3578]

LGTM