[OffgridwithJD]

Fixes #1327, which you filed while reviewing #1325.

The bug

ALTER COLUMN ... TYPE text COLLATE <other> keeps the relfilenode, so no zone map was rewritten. The stored minima and maxima were the old collation's, and the reader compared them under the new one. Red first, on PG17 at 11f954e, against heap:

query after C → en_US.utf8	columnar	heap
min(s) || '|' || max(s)	B0|m6	a0|m6
count(*) WHERE s < 'B'	0	750
count(*) WHERE s = 'a0'	0	107
a columnar partition, ALTER through its partitioned parent	wrong
a projection sorted on the column, range	wrong

column_extent() also still printed the C bound.

The fix: forget the bounds rather than recompute them

The ProcessUtility hook handles any ALTER TABLE that changes a column type.

• Before the statement, it records each columnar relation's relfilenode and column collations from the syscache. That covers the named relation and every inheritor, which is how an ALTER on a partitioned parent reaches its partitions. It does not open the relations, so it takes no lock that the ALTER would then have to upgrade.
• After the statement, for each relation whose relfilenode is unchanged (not rewritten), every column whose collation changed gets PgColumnarForgetColumnOrdering:
  • The zone-map minima and maxima are nulled, whole-chunk and per-vector, in the base storage and in every projection storage. A projection stores [rownumber, cols…], so its column index is the list position + 1.
  • The column's extent rows are deleted.
  • Counts and sums stay, because no ordering decides them.

A zone map with values and no bounds is already the state a type with no ordering writes, and the readers treat it as "nothing known":

• no pruning;
• expire keeps the group;
• the extent recompute refuses, so the extent stays absent until a rewrite.

One reader was wrong about that state. The ungrouped min/max fold skipped such a group as if it were all NULL, and returned NULL where heap returned a value. It now sends the group to be read, as it already does for an added column.

Recomputing instead would decode the column in every group, inside the ALTER and under its ACCESS EXCLUSIVE lock. Not rewriting was supposed to spare the user exactly that cost. A later rewrite builds correct zone maps, either vacuum_sorted/pgcolumnar.vacuum or a type change that does rewrite.

The sorted-pathkeys claim was already safe. It refuses every collatable column for exactly this reason. vacuum_sorted's ORDER BY arm is green on main and is that refusal's guard, dated by a mutant that removes it.

Found on the way

PgColumnarReadExtentRows was first given an unregistered GetLatestSnapshot(). PG18 asserts a heap scan's snapshot is registered, so every collation change aborted on the 18 and 19 assert builds. Caught by the five-major run and fixed in its own commit.

Evidence

• collation_change.sh (11 checks) and the independent test_collation_change.py pass on PG15–19, with no TRAPs. The twins grade 12/12, the 12th being the shell's pgc_skip name, mirrored by the twin's cannot_run.
• Seven mutations, each red on its own arms:
  • nothing forgotten (7 arms);
  • projections skipped;
  • the projection index off by one;
  • the named relation only;
  • the min/max fold guard removed;
  • the extent kept;
  • the sorted claim's collation refusal removed.
• Ledger: 11 rows, 8 dated, 3 never (all premises). Rebased onto 4c72242 (feat: a no-op expire answers from the column's extent, not a zone-map probe per group (#1310) #1326): 1796 → 1799 over 2270 rows. The gate gives rc=0, and suites_not_covered stays 246.
• PG17 neighbours: native_agg 35/35, native_agg_addcolumn 17/17, native_agg_deletes 8/8, native_zonemap 18/18, sorted_pathkeys 113/113, projections 73/73, projection_rewrite 84/84, column_extent 36/36, alter_column_type 21/21, docs_style 58/58.
• Guard half 419/419. cluster_tests 525 → 526. TESTS.md section 103. CHANGELOG Fixed.

A server with no en_US collation fails the shell suite. pgc_skip passes it only when PGC_ALLOW_MISSING_EN_US_COLLATION=1 waives it, and the twin's cannot_run makes the run INCOMPLETE. Neither can pass vacuously. CI's Ubuntu images have en_US.utf8, but I haven't confirmed that inside the cluster jobs; this PR's CI will.

🤖 Generated with Claude Code

[jdatcmd]

Approved at e21d3f3. Merging when CI is green on this head.

The risk I most wanted to rule out is closed. Could a projection sorted on the column still supply ORDER BY in the old collation's order? That would be wrong even with the bounds nulled. It can't happen: the sorted-scan path refuses any column with a collation (columnar_customscan.c, OidIsValid(att->attcollation)), and the comment there records this very case. Probed on PG17: ORDER BY s LIMIT, DISTINCT ... ORDER BY and GROUP BY ... ORDER BY all plan a Sort (s COLLATE "en_US.utf8"). Range and equality reads through the projection match heap.

Aggregates and awkward ALTER shapes, all matching heap on PG17:

• min/max under the default plan, the ungrouped fold (with and without a filter), and the grouped path;
• a collation change plus a rewriting type change (rewritten, fine);
• a collation change plus ADD COLUMN (6/6 bounds nulled);
• a rolled-back ALTER, a savepoint rollback, ALTER then a read in the same transaction, and a DO block;
• a partitioned parent with a heap and a columnar partition.

A domain with the same C collation nulls nothing, so no bounds are lost.

Runs at e21d3f3:

• collation_change.sh: 11/11 on PG17, PG18 and PG19. PG19 is not in CI's build matrix.
• test_collation_change.py on PG17: green.
• native_projection.sh on PG17: 8/8.

The ledger is right. Main's rows are unchanged. 2270 rows, of which 1799 are never red, equal to the budget. The three never-red collation rows are premises.

Not examined: dump/restore and pg_upgrade of nulled bounds.