Test coverage: aarch64 (and big-endian) — alignment/endianness class is x86_64-only

[ChronicallyJD]

Gap

All testing is x86_64. There is no aarch64 (Graviton / Ampere / Apple Silicon) coverage and no big-endian coverage, in either the local matrix or CI.

This matters concretely, not theoretically:

• The clang ASAN+UBSAN gate exists because Fuzz the Parquet decoder, and fix the first defect it found (#214) #225 was an unaligned varlena-header read that is benign on x86_64. aarch64 has stricter alignment and can fault where x86 silently tolerates, so the exact class the sanitizer gate was built for is the class only x86 is tested against.
• The Parquet/Arrow decoders do explicit byte-order handling (native_parquet_flba.sh: big-endian FLBA, little-endian widening), and the native on-disk encoding descriptor is host-endian (columnar.h:56). An endianness bug is untestable on the current fleet.

Why this blocks a public release

aarch64 is now a mainstream deployment target (a large share of cloud Postgres). Shipping "supported" while never having run there, on the very alignment class already found once, is a real regression risk. Big-endian is lower priority (rare) and acceptable-with-caveat.

Suggested acceptance criteria

• Run the suite matrix on an aarch64 runner (GitHub ubuntu-24.04-arm or equivalent), at minimum the assert build + core write/read/encode/parquet suites.
• Document big-endian as untested if not covered.

Found in a release-readiness review.

[jdatcmd]

Deferred by the owner; recording the state so this is cheap to resume.

A scope correction that matters for the acceptance criteria

This issue argues for aarch64 partly because "the exact class the sanitizer gate
was built for is the class only x86 is tested against". I built the job, ran it,
and that reasoning does not hold.

ARMv8-A under Linux permits unaligned accesses to Normal memory for ordinary
loads and stores; SCTLR_EL1.A governs alignment checking and Linux leaves it
off. Only exclusives and atomics require alignment. So the #225 unaligned
four-byte varlena-header read would not fault on aarch64 either, and an
aarch64 leg would have passed before that fix landed.

aarch64 is therefore portability coverage -- codegen, atomics, memory
ordering, word-size assumptions -- and not alignment coverage. The two should be
separated here, because otherwise a green arm leg reads as "the alignment class
is covered" when it is not.

The alignment detector is UBSAN, in the #230 sanitizer gate, on the hardware
we already have. Testing strict alignment for real would need a genuinely strict
target (SPARC, older ARM) or trapping via SCTLR_EL1.A, which userspace cannot
reach. Neither is worth chasing while UBSAN covers the class.

What exists, ready to resume

Branch ci/aarch64 (PR #246, closed as deferred) adds a ubuntu-24.04-arm
suites job stacked on #236. It has been run:

uname -m: aarch64
98 suites PASS      ALL VERSIONS PASSED      1m55s
skips: PGC_SKIP_TIMING only -- no pyarrow skip, so Arrow and Parquet ran

The open questions a first run would normally have to settle are already
answered: arm runners are free for public repos, PGDG has arm64 for every
component installed, pyarrow has an arm64 wheel, and no suite fails on aarch64.

Big-endian

Untouched and a separate question. aarch64 is little-endian. The on-disk encoding
descriptor is host-endian by design (columnar.h:56) and docs/limitations.md
already documents Arrow and Parquet as little-endian only. The only
WORDS_BIGENDIAN in the tree is in ColumnarVarSizeAnyUnaligned, added by #225
and never compiled on such a host. Documenting big-endian as untested is the
honest resolution unless someone wants the gate.

[ChronicallyJD]

Agreed, and thanks for building and running it. My rationale conflated aarch64 with alignment coverage, and that was wrong: ARMv8-A under Linux permits unaligned accesses to Normal memory (SCTLR_EL1.A off), so the #225 unaligned read would not have faulted on aarch64 either. aarch64 is portability coverage — codegen, atomics, memory ordering, word-size — and the alignment class is UBSAN's job in the sanitizer gate, on the hardware we already have. Big-endian as document-only is the honest resolution given the host-endian on-disk format. The useful outcome is that ci/aarch64 is written and proven (98 suites, 1m55s, no pyarrow skip); resuming it is cheap.