docs: state the alpha5 tagged state (merge with the tag)

[jdatcmd]

Draft. Do not merge before the owner approves the tag. Once merged, the four sentences below say alpha5 is published, so this PR and the v1.0-alpha5 tag go together. The owner asked to approve the tag before it is pushed.

What changes

• RELEASE_NOTES_1.0-alpha5.md: release date 2026-10-13, to be adjusted if the tag is cut on another day.
• CHANGELOG.md: ## [Unreleased] becomes ## [1.0-alpha5] - 2026-10-13. The alpha4 close (e1083a9) did the same.
• Four sentences say v1.0-alpha5 is the latest published pre-release: the CHANGELOG header, README.md, docs/installation.md and docs/roadmap.md. The alpha4 tag commit (6bd60de) changed the same four.

docs_style: one check fails locally, as expected before the tag exists. "v1.0-alpha5 carries a dated section of its own to compare against" reads got [no section for 1.0-alpha5 at v1.0-alpha5]. The check compares every dated section with the same section at its release tag, and v1.0-alpha5 doesn't exist yet. CI skips it, because its checkout has no tags. Once the tag is cut from this commit, the comparison is of the section with itself, and it passes. I'll rerun docs_style after tagging and post the result. This is one more reason to merge and tag together: between the two, a local docs_style on main is red. Everything else in docs_style passes.

A question for @OffgridwithJD

Several documents say "native format, PGCN v1": README, docs/features.md, docs/index.md, docs/roadmap.md, ARCHITECTURE.md and the CHANGELOG header. Since #1137, a table this release writes carries format version 2, as docs/testing.md and the release notes say. Is "PGCN v1" the format family, so it stays right, or should these say v2? limitations.md:58 seems to treat them as two numbers. You built #1137, so your call.

Before the tag, on this exact tree

• extension_upgrade.sh v1.0-alpha4 on PG15–19. It already passes at b55cb23, with 211 objects byte-identical.
• The full matrix and pytest on PG15–19. A clean-rebuild run is in progress at 614eb02; I'll rerun on this head.
• Then I ask the owner, merge, tag, and capture the fixture from the tag.

🤖 Generated with Claude Code

[jdatcmd]

Full run on clean builds, for the tag. At the owner's request, every PostgreSQL install and pgColumnar build on my machine was removed. PostgreSQL 15.18, 16.14, 17.10, 18.4 and 19beta2 were rebuilt from release tarballs, checksums verified, with the same cassert/debug flags as before. Contrib, hll 2.19 (15–18), tdigest 1.4.3 and pg_partman 5.4.1 are installed on every major. pgColumnar was built fresh by the matrix at main 614eb02.

run_all_versions.sh, 15–19:

• PASS on PG15, PG16 and PG17 (278 ran each), and on PG18 (281 ran). The skips are the version-gated suites.
• PG19: 283 ran, and one check failed: projection_parallel's "workers share the covering projection scan", got [1] want [2]. It passed 11/11 on three reruns of the same build. That is a timing-dependent arm, filed as projection_parallel: the worker-sharing arm fails when one worker claims every stripe before the other starts #1336.
• logical_decoding_* and partman_columnar now pass on every major. Their earlier failures were the missing test_decoding and pg_partman.

Full pytest, 15–19: 945 passed on each. The two remaining failures on each major (test_build_refusal's fingerprint test and the guard test that wraps it) came from my checkout living in a mode-0700 directory: the test's unprivileged reader couldn't open the module. From a traversable checkout, both files pass on PG17 (58 passed, 176/176 checks).

This was at 614eb02. Main has since gained #1334, #1333 and #1332, so I'll rerun the upgrade test and the matrix on this PR's exact head before asking the owner for the tag.

[jdatcmd]

A correction to my results comment above. It said pytest was 945 passed per major, with two failures that were the environment. It missed a third outcome, on PG15, 16, 17 and 19. test_native_groupagg.py::test_a_non_deterministic_collation_key_falls_back was unrunnable and not expected to be: it needs a non-deterministic ICU collation, and those four servers of mine were built --without-icu, the same flags as the old installs. PG18 has ICU and ran it. That outcome turns the exit code red on its own; I read only the FAILED lines and missed it.

So it isn't a product failure, but it is a test that didn't run on four majors. CI's PostgreSQL packages are built with ICU, and my builds should match. I'm rebuilding 15, 16, 17 and 19 with ICU and will rerun the full pytest on all five. The numbers in this PR will then be complete.

[OffgridwithJD]

@jdatcmd On "PGCN v1": it names the format family, so it stays. The format version is a separate number inside that family, and #1137 moved only the version.

src/columnar.h keeps the two apart:

• "Native format (PGCN v1)" is the on-disk data format: its magic (COLUMNAR_NATIVE_MAGIC "PGCN") and the design in design/NATIVE_FORMAT_AND_INTERFACE_SPEC.md. Neither changed in alpha5, which is why the release notes say "The native data format stays PGCN v1."
• pgcolumnar.storage.format_version (COLUMNAR_NATIVE_FORMAT_VERSION) is the per-table stamp inside that family: 1 through alpha4, and 2 from alpha5 (opt: the validity bitmap is stored uncompressed and never elided, and is 99% of a well-encoded page #1130's bitmap-less chunks).

So README, features.md, index.md, roadmap.md, ARCHITECTURE.md and the CHANGELOG header are right as they stand.

The one sentence that conflates them is limitations.md:58: "The first is a native data format version, which is PGCN v1 at this time." Two paragraphs later the same section says "The native format version is 2 from 1.0-alpha5." Suggested replacement for that sentence:

The first is the native data format version (pgcolumnar.storage.format_version), which is 2 from 1.0-alpha5, within the PGCN v1 format.

Your fingerprint failures: #1338 fixes them. The unprivileged read now uses a copy of the stdlib-only module in a traversable temp directory, plus the base interpreter. It also runs extension_upgrade and format_downgrade from /, which hit the same thing on my 0750 home. As root from that home with a 0700 venv, test_build_refusal.py passes 39 and test_harness_deps.py 19. #1338's other half, the temporal and native_repack changes, only matters on 19beta4. On your 19beta2 build those suites behave as before. It's tests and CI only, so it doesn't need to hold the tag.