GH-46623: [C++][Compute] Fix the failure of large memory test in arrow-compute-row-test

[zanmato1984]

Rationale for this change

In #45336 we refined the row table buffer accessors and enforced the validation on who can call the var_length_rows() method. However a legacy test CompareColumnsToRowsOver4GBFixedLength is leveraging this accessor to assert this buffer being null.

What changes are included in this PR?

We can just check if the row table is fixed length.

Are these changes tested?

Yes.

Are there any user-facing changes?

None.

• GitHub Issue: [C++] Large memory test fails in arrow-compute-row-test #46623

[zanmato1984]

I guess the CI won't tell us anything (the large memory tests are not ran by default). Feel free to try in your local @pitrou . Thanks.

[pitrou]

I guess the CI won't tell us anything (the large memory tests are not ran by default).

Yes. For the record, I've opened #46600 for it (and this is how I found out that this test was failing).

[pitrou]

Rebased in the hope of getting greener CI./

[pitrou]

LGTM :)

[pitrou]

Rebased in the hope of getting greener CI./

Well, of course, this is a bit futile since the test won't run anyway. I'll merge :)

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit c2fb0e3.

There were 68 benchmark results with an error:

• Commit Run on arm64-t4g-2xlarge-linux at 2025-06-02 18:41:23Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-07, scale_factor=1
  • tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-09, scale_factor=1
• and 66 more (see the report linked below)

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.